Ron Bodkin's Blog

The Rich Web Experience

I'm looking forward to speaking at The Rich Web Experience conference in San Jose next month. The event runs from September 7th through 9th. I'll be presenting on Rich Web App Performance and Scalability and Managing Client State Across Domains. I'd love to hear comments on specific topics or questions that are of interest.

I hope to see you there! Also, there's a special $200 discount available if you use the promotion code nfjs2007speaker200 when registering.

Glassbox Lab at JavaOne Today

This is just a quick note to let everyone know that MaxPoon and Paul Cheung are doing a lab session with hands on Glassbox content at JavaOne today from 1:30pm to 3:30pm. I'll be there also to answer questions. Here are the details:
Nonintrusive Monitoring of Java Technology-Based Applications with Java Management Extensions (JMX) Technology, JConsole, and Aspect-Oriented Programming: Using a Spring Application as an Example

This is at Moscone Center - Hall E 130-132

I hope to see you there!
Ron

Two Useful Aspects

Sometimes it's refreshing to write a useful little aspect. Just last night I was reviewing some code that colleagues wrote for thread safety and I found this to be a really efficient way to find likely danger spots:

public aspect TrackCollectionAccess {

    declare warning: set(java.util.Collection+ *.*) || get(java.util.Collection+ *.*): "collection field access";

    declare warning: set(java.util.Map+ *.*) || get(java.util.Map+ *.*): "map field access";

}

I was able to weave this into the project and quickly review places in the code where fields containing collections and maps were being used to see if they were used in a way that wasn't thread safe. This is a nice example of a development-time aspect: using them to help you develop without using them in production.

On the other extreme, I recently extended Glassbox to allow for various kinds of application-specific plugins. There are a number of points where plugins need to interact with the underlying system, and it turns out to be a good example of how you can use aspects to modularize a feature variation. For example, here is how the DefaultPluginManager aspect allows a plugin to define new kinds of operations:

    Object around() : getOperations() {

        Collection result = (Collection)proceed();

        for (Iterator it=operationPlugins.values().iterator(); it.hasNext();) {

            OperationPlugin plugin = (OperationPlugin)it.next();

            Collection added = plugin.getOperations();

            if (added != null) {

                for (Iterator inner=added.iterator(); it.hasNext();) {

                    OperationSummary summary = (OperationSummary)inner.next();

                    summary.getOperation().setPlugin(plugin);

                }

                result.addAll(added);

            }

        }

        return result;

    }

Learning About Aspects

I enjoyed being back at a couple of No Fluff Just Stuff conferences this fall (including the Rocky Mountain Software Symposium this past weekend). Jay Zimmerman continues to do a great job of providing fresh technical content with great speakers and it's always fun to talk the audiences at these about topics like Glassbox, AOP, and AJAX.

For those who are interested in digging in to aspects more deeply, I highly recommend the Aspect Leadership Program (ALP), which will be held in Vancouver this March 14th and 15th.

The ALP is an opportunity to learn from seven of the world's leading experts, who will provide a two-day crash course on everything you need to know to figure out what aspect-oriented programming (AOP) is all about; identify whether and how you can use it to add value, drive quality and improve productivity in your enterprise; and provide practical guidance on implementing AOP. I'm also proud to be part of the presenters at this event. Please pass on the word about this to others who might be interested, too!

AOP at the Colorado Software Summit

I'm enjoying another year of presenting at the Colorado Software Summit. One of my talks is about AOP with Spring 2.0, covering both the use of Spring AOP and of AspectJ within Spring. I've really enjoyed some of the dialog with attendees when I give this talk and afterwards: it's great to hear how people are making real use of AOP and new ideas for additional uses.

At one bank, they are using Spring AOP with Spring MVC to scan incoming Web requests for SQL injection attacks. In another department they are using AspectJ to implement use cases separately such as sending email notifcations after business events, supporting state-specific regulations in a Web application, handling encrypted fields and white space trimming on Web requests. Another group is looking to detect resource failures and short-circuit requests that would use them to avoid tying up threads (while checking for restored availability periodically). This is an interesting scenario for integrating with Glassbox to detect the outages, with custom logic to manage requests when there are outages.

Another interesting use case I heard about is audting data when committing transactions using Spring AOP. It turns out you can use the Spring ordered interface to ensure the audit logic can set up just before the transaction commits (so it can be included in the transaction!). However I don't see how you specify the order of the transaction aspect in @AspectJ aspects in the relevant Spring docs as of today (Oct. 25): it is shown in the XML schema-defined .

In my talk I also give an example of how to use Spring AOP to proxy persistent objects after a DAO returns them by executing advice after they are returned, say by a finder method in a DAO. Now this isn't as nice as using AspectJ to configure and otherwise advise these objects, but it can be a useful approach for those using Spring AOP but not yet AspectJ.  This code uses the ability to explicitly create @AspectJ proxies in Spring AOP code, which is also fine.

It's been interesting working a bit with @AspectJ with Spring: you can get good tools support by turning on AJDT while being ableto preserve very natural incremental development in Eclipse. I'm still continuing to use traditional AspectJ syntax for my projects, but like Spring AOP it can be very useful in projects that are starting to adopt AOP:

...
        @Pointcut("execution(music.model.Playable music.model.PlayableDao.find*(..))")
	void createPlayable() {
	}
	
	@Around("createPlayable()")
	public Playable proxyPlayable(ProceedingJoinPoint pjp) throws Throwable {
		Playable created = (Playable)pjp.proceed(); 
		return proxyPlayable(created);
	}

	public Playable proxyPlayable(Playable playable) {
		AspectJProxyFactory factory = new AspectJProxyFactory(playable);
		factory.addAspect(this);
		if (playable instanceof PlayList) {
			proxyChildren((PlayList)playable);
		}

		return (Playable)factory.getProxy();
	}

	void proxyChildren(PlayList playList) {
		for (ListIterator
 it = playList.getEntries().listIterator(); it.hasNext();) { 
			Playable child = it.next();
			Playable proxy = proxyPlayable(child);
			it.remove();
			it.add(proxy);
		}
	}

Glassbox at Google Video and Elsewhere

This was a big week for Glassbox. We started off by presenting a tech talk on Java Troubleshooting with Glassbox at Google we had some great feedback at the talk and a lunch before and are looking forward to further feedback as teams there try the technology.

Later this, week I also had a good on site visit with a major business information provider where we installed and tested Glassbox on Weblogic and Tomcat for a variety of interesting applications. We also started work on integrating with a high availability system for a hospital, to provide performance and liveliness data. We are looking to provide more rich API's to allow writing custom extensions and deeper integration with Glassbox. We see a great opportunity to extend our monitoring with focused, application specific descriptions of components, service level agreements, and metrics. The idea is that you should be able to get useful data out of the box but can leverage the power of AOP to get more insight with a small investment. I'd love your input on this.

Live Glassbox demo

We just posted a new feature for Glassbox on our Web site this week: a live demo of Glassbox running against our "cranky" Pet Store, showing how it can diagnose problems in an application. This is a great way to try out Glassbox and to share it with colleagues. Behind the scenes we're running Tomcat with Glassbox and JPetstore  and MySQL and using a nice open source load testing tool, OpenSTA, to create sample load. The JPetstore application has a few extra problems added but we made no changes to integrate with Glassbox. I'd be interested in your feedback...

Glassbox 2.0 automated troubleshooter Goes Beta

I'm pleased to announce that we just shipped the Beta release of the open source Glassbox 2.0 automated troubleshooter. Glassbox 2.0 is a major step forward in simplifying troubleshooting enterprise Java, just deploy it to your app server and it discovers your existing applications and automatically diagnoses problems. Glassbox provides a concise analysis of what’s wrong, focusing on relevant information like excessive queries, or parameters that cause failures.

Glassbox now offers an AJAX Web Client, improved analysis and an automated installer that makes it easy to monitor Java applications in either a standalone or clustered environment.  Under the hood, Glassbox continues to improve its monitoring and analysis to more easily pinpoint problems, Glassbox monitors selectively to allow very low overhead data capture, and we have been working with the AspectJ project to significantly reduce memory and startup time overhead. Glassbox is all open source with our CVS repository now hosted at SourceForge.

Please try it and let us know what you think.

We’d enjoy showing you in person, too. We’re presenting Glassbox this fall at:

• Software Development Best Practices Sept. 12 in Boston
• Google on Sept. 25 (to be available on Google Video afterwards)
• Bay Area Software Symposium Oct. 13-15 in San Jose
• The AJAX Experience Oct. 23-25 in Boston
• The Colorado Software Summit Oct. 23-27 in Keystone
• Rocky Mountain Software Symposium Nov. 10-12 in Denver

Stupid Log Tricks: Avoiding Nondelegation

I have been fairly quiet recently as we've been heads down working on an alpha release of Glassbox 2.0, with a focus on further ease of use in troubleshooting Java applications.  Most of the Glassbox functionality will be deployed as a portable Web application that is easy to install and run (except for the parts that have to integrate at a system level to monitor applications).

However, making a portable Web application is challenging because of nondelegating loaders and, you guessed it, logging. Of course, Jakarta Commons Logging is both widespread in its use and as Ceki Gülcü illustrated, there can be a number of problems with how it functions when you have a copy of it deployed to a shared location on a server AND inside a Web application with nondelegating classloaders. We have to support it because libraries we use like Spring use it. However, it turns out that there is a portable work-around: force your Web app's parent loader to load the classes in JCL before  you use logging:

    private void eagerlyLoadCommonsLogging() {

        String classes[] = {

                "org.apache.commons.logging.Log",

                "org.apache.commons.logging.LogFactory",

…

                "org.apache.commons.logging.impl.NoOpLog"

        };

        ClassLoader myLoader = getClass().getClassLoader();

       

        if (myLoader != null) {

            ClassLoader parent = myLoader.getParent();

            for (int i=0; i<classes.length; i++) {

                try {

                    Class.forName(classes[i], false, parent);

                } catch (ClassNotFoundException cne) {

                    // ok - not present in parent

                }

            }

        }

    }

Of course this exercise isn't limited to logging: any library that a portable Web application uses can have problems like this. But logging is crosscutting, widespread and often used. Some of the forces that make this exercise particularly challenging for us are:

1. We don't want to require log4j, commons logging, or slf4j to be installed on the system class loader.
2. We don't want to ship many different versions of the app, one per environment
3. We don't want to modify the Web app during installation (e.g., to remove overlapping versions of the libraries)
4. We don't want to require configuring our app manually (e.g., plugging in a different logging adaptor as slf4j does)
5. We need to work with older versions of libraries (e.g., that eager loading code could find JCL 1.0!)
6. We want to configure logging for shared classes that are typically on the system classpath (or in the equivalent of Tomcat's common loader). This last one requires us to set the context ClassLoader when initializing a log inside our library (good thing we manage logging with aspects!)

Of course, if you'd like to configure how logging works (e.g., redirecting to files, not leaving on overly verbose INFO logging for used components etc.) you still have to do that programmatically or ask users to configure their global log settings. Indeed, setting them programmatically has its own problems for shared libraries (the configuration would be global).

This is an area where reuse hurts. If you use an emerging logging implementation today you will probably not have any conflicts with existing code. In three years, you may find a lot of them. This is also the reason that tools like jarjar exist. Of course, this is typical for successful component models: they have to become popular before people take isolation and versioning seriously... remember when Java developers were glad that we didn't suffer from DLL hell?

See Glassbox at JavaOne

If you are at JavaOne this week, make sure to see Rob Harrop demonstrate a preview of the next generation of Glassbox tomorrow (Friday) at 1:15pm at Designing Manageable J2EE™ Platform-Based Applications With JMX™ Technology with an Ajax Web application that provides summaries of application problems like failing connections or slow remote calls and JMX console integration for detailed drill-downs into applications. Here is a preview:

Rob and I spent some time yesterday to discuss Glassbox and to get him a preview of our new technology. Rob, Keith Donald (who leads Spring Web Flow) and I also discussed how Glassbox can use with Spring AOP to provide deep insight into Spring applications with negligible overhead.

I've also been enjoying catching up with friends and meeting new people at JavaOne parties. Thanks to Simon Phipps, BEA and Tangosol, and Geronimo and partners for hosting some great festivities. To me, the big story at this JavaOne is how open source technologies built on Java are winning at every level. Whether in Web application frameworks or application servers, the primary contenders are increasingly open source...