In the Spotlight - Alef Arendsen

Three weeks ago, the SpringSource Tool Suite was released. Christian, in charge of this product blogged about it already and we also have a webinar available for those of you that want to get up to speed with all of the functionality it currently offers. In this entry, I wanted to highlight the runtime error reporting functionality specifically.

When I'm programming, sometimes, the console window shows dozens of stack traces due to some error I've caused. Sometimes, I'm lucky and the stack trace looks familiar. If so, then the problem is probably easy to solve. Sometimes however, the information you need is buried so deep inside all those stack traces, that figuring out what the real problem is takes a while.

With the introduction of the SpringSource Tool Suite, we've started to build up a online knowledge base that includes resolutions for common problems you might encounter. Using the knowledge base, you no longer have to browse through pages and pages of exception stack trace information. Instead clicking a simple button will run a query over the knowledge base and if possible cause is found, you automatically get relevant information that will help you solve your particular problem. The quick screencast below should give you some insight into the functionality. Note that the full screen functionality of blip.tv works fairly well, so in case the fonts are a bit small in some parts of the screen cast, using the full screen mode solves this.

We have just started out filling the knowledge base and with the release of the tool suite, it'll probably contain a wealth of errors already. But obviously, the knowledge base cannot hold a resolution for every problem you might encounter. That's why we are constantly adding information about potential errors ourselves, but also allow you to add particular error conditions with suggested solutions. Authoring tools are available directly inside the IDE, so you don't have to bother about using some kind of proprietary XML format. All content submitting by you (and other developers) will periodically be reviewed and released as an update to the knowledge base. In a next screen cast, I'll highlight this functionality.

I'm am really excited about this particular feature of the SpringSource Tool Suite as it will help me get my errors out of the way much quicker than in the past. If you're interested in reviewing the SpringSource Tool Suite, please visit the product page on our web site where currently, you can download a beta after having registered. On that page, we also have a longer webinar available in which Christian Dupuis explains the SpringSource Tool Suite in much more detail.

It's been a while… for the Amsterdam Java Meetup that is. I've been traveling a lot and haven't been able to organize another meetup past quarter. But here we go again: the (almost) quarterly Amsterdam Java Meetup with free drinks (or at least, the first few rounds) will be hosted in grand-cafe de Jaren in Amsterdam (see below for more info on the location) on the 23rd of May. You can expect many Java devs (usually between 50 and 80 people turn up), technical as well as non-technical discussions and of course, the latest gossip in the Dutch Java industry. We'd love to hear from people from 'the other side' (other other sides, I should say) as well, so if you're doing Ruby or .NET, don't hesitate to join in too!!

Spread the news and link to this blog entry or to the corresponding Upcoming.org page. You're welcome to leave a comment if you're attending. See you there!

View Larger Map

I'm writing this as I'm on my way to Cairo. We're flying just West of Italy and I have clear view on the Italian coast line, with its blue waters and waves gently moving towards shore. It must be nice down there now. I'm heading to Cairo for a meeting of the Egyptian User Group, organized by Ahmed Hashim, who no doubt will have done an excellent job, I'm sure of that. I'll be presenting on Spring with the theme this time being Dependency Injection, type safety and Java 5. Yesterday (March 14th that is), I did almost the same presentation at the Profict Wintercamp in Loenen, NL for an audience of 60 of 70 I think.

Lately there has been a lot of talk about type safety, Spring and other dependency injection approaches. Way too often, I found people referring to Spring as having dependency injection features that are not type safe and even worse, people that were referring to Spring as having a dependency on XML . As I can't keep looking out the airplane window for ever (well, I probably can, but it's not that useful), I figured I'd write a little blog entry on the current status of dependency injection with Spring and Java 5.

With the addition of features in Spring 2.5 and also with Spring's sub project JavaConfig the type safety argument and the argument that Spring is tied to XML is simply not true anymore. While in the past, we've always said that Spring was not coupled to XML, surely the only viable option of expression your configuration details was XML. But since Spring 2.5, this is no longer a theoretical argument; there is a practicably usable option for configuring your dependencies using plain Java.

Spring @Autowired support

Spring 2.5 itself provides annotation-based dependency injection, where hints are giving to the Spring container where to inject dependencies using @Autowired annotations and @Qualifier annotations (or any other custom annotation for that matter). I will not cover the entire mechanism here. Instead, I'll highlight the blog entries and articles that cover the @Autowired approach:

• Introducing the Spring Framework 2.5 by Rod Johnson
• Spring 2.5's Comprehensive Annotation Support by Juergen Hoeller
• Customizing Annotation Configuration and Component Detection in Spring 2.5 by Mark Fisher

Spring JavaConfig

In addition to the @Autowired support, Spring JavaConfig provides a entirely new approach to dependency injection. Plenty of blog entries have been talking about JavaConfig already, so I won't fully explain it here again. I got several questions recently about the status of JavaConfig. We haven't published any milestones for this project in a while. This certainly not without reason. Although the model already works quite well, we are still not done fleshing out some of the details. We want to release something we're 100% happy with and right now, it's simply not
done yet. Keep an eye on the JavaConfig project page and this blog. A new milestone release is just around the corner.

The JavaConfig approach is highlighted in more detail in various blog entries as well:

• Spring Java Configuration Moving Ahead by Rod Johnson
• A Java Configuration Option for Spring by Rod Johnson
• More on Java Configuration by Costin Leau
• Guice vs Spring JavaConfig: A Comparison of DI styles by Craig Walls
• Spring: Prototype Scope, Lookup Methods and JavaConfig by Solomon Duskis
• IoC and Modularization - Spring, OSGi, Guice and more by Solomon Duskis
• Spring Configuration Annotations by Solomon Duskis

As I've also said in the sessions in Loenen and in Cairo, Spring JavaConfig is not yet done. There are still a few details to be fleshed to create a smooth DI language that supports all the features that the XML-based DI language also has. This is where (if you like) you can help us a lot. Try Spring JavaConfig and tell us what you think!

Conclusion

One other quite important point I tried to get across in my presentation yesterday and that's the idea of the Spring container as a dependency injection platform, with various DI flavors implemented on top of it. The first flavor, has existed for 5 years already (the XML-based approach). The second has also been around for quite a while already and now provides the basis for the EJB3 SessionBean functionality inside BEA WebLogic version 10 (and is also available in the public domain under the name Pitchfork). The last flavor that we released is the @Autowired flavor and next up is JavaConfig. Having the platform is what counts for us. It'll help us get you an nice experience with full backwards-compatibility, whether you're using
JavaConfig, @Autowired or our XML-based approach (or, all at the same time for that matter).

A word on the source code and slides

In the slides you will see I've included an image of a Ford Model T. The analogy that I always use when describing Dependency Injection is a car assembly line. Without the car assembly line (according to Wikipedia), Ford could produce 11 Model Ts per month. With the assembly line one Model T took only 93 minutes. A standardized process of assembling parts (that do not know how they are going to be assembled) into a working car is very beneficial. In my opinion, having an approach that does not touch your main-line logic is important. JavaConfig offers this.

The code is attached as well. There is a dependency on the JTA API (the demo uses Hibernate), which is not installed in the Maven Repository. Lucio Benfante has blogged about solving this problem (installing the JTA API in your local repository).

After you've installed the JTA API, run the CarPlantIntegrationTests in the com.carplant.plant package and read the comment for the class. This explains how to enable JavaConfig, Autowire config and the XML config (JavaConfig has been enabled by default).

• The source code: carplant.zip
• The slides: di_with_spring.pdf

[update] added one more resource on JavaConfig

At The Spring Experience, I hosted a session various aspects. One of them was the Hibernate synchronization aspect that I described last week. Another was an aspect capable of capturing first failures and system state, sometimes called First-Failure Data Capture (FFDC). I hosted this session to show off some aspects that are very useful, but that people might not have come across in practice yet. I often hear people asking about aspects other than logging, tracing, transaction management and security. The Hibernate synchronization aspect and the FFDC aspect are nice examples I think.

Introduction

The objective of FFDC is to capture as much information about the current state of the system when an error occurs. The following entry explains how this aspect works and how you can use in your own applications.

Let's set the following two goals:

• When a failure escapes from a business service, we want to log the call context, meaning all calls that have happened in the context of this execution of the business service
• When a failure escapes from a business service, we want to log the root cause of the failure, meaning not only the top-most exception (the exception that escaped from the method), but also the first exception that was thrown that might have been wrapped, swallowed or re-thrown

In order to do this, first let's devise a class that is capable is keeping track of the data for us that we want to record. We will call this class the CallContext. I'm omitting the actual implementation. I'll post the code in my next entry, the implementation does not really matter here and other than that, it's a pretty straightforward data holder anyway.

As you can see, we are using the AspectJ JoinPoint type to identify an event happening in a program.

Defining four scenarios

So, we've got the data ready. Next, let's rephrase the two goals we've set previously a little bit and create a list of things that we want to have happening in our program(s):

• Before a call to a business service, we want to register the root call with the current call context
• Before a call in the context of a business service, we want to register the (and the current depth) call with the current call context
• When an exception occurs inside a business service, register it with the current call context as the first failure
• After an exception escapes from a business service, we want to log the current call context

As you can see, I'm just slicing and dicing things a little in such a way that sentences in the form of 'before/after something happens, do something' start appearing. The only thing left to do is to identify the two somethings and we're done. Let's tackle each of the three different pieces of logic individually.

Before a business service, register the root call with the current context

Using AspectJ, this is relatively simple to do. Let's assume a business service can be identified by a @BusinessService annotation that can be added to a method or a class. In case it's added to a class, all methods on that class are business services. In case it's added on to a method, that method alone is a business service. In other words: a business service is a method defined in a class that in its turn is annotated by @BusinessService or a method that is annotated by @BusinessService itself. In AspectJ this comes down to the following (for more information on the exact syntax of the AspectJ pointcut expression language, refer to http://www.eclipse.org/aspectj//doc/released/progguide/semantics-pointcuts.html).

Now we have identified a business service, we can finish the first scenario:

Before a call in the context of a business service, register it with the current call context

We're done with the first scenario, let's tackle the second scenario. We have already identified what it means to be a business service. We want to trap all calls in the context of business services. An arbitrary call can be identified as follows:

If we'd use this pointcut, we'd make the scenario applicable to all methods, but we only want to apply it to methods inside business services. Therefore we need to limit the scope of this pointcut. We can do that by using the cflow pointcut designator. The cflow pointcut designator takes another pointcut and limits to the things happening in the context of that pointcut. Let's see how we can use it to solve the problem at hand. Read the following as: 'a method call in a business service is a method call (refer to pointcut defined above) while (and) in the control flow of a business service (refer to other pointcut defined earlier'.

Let's go one step further and say that we do not want to register all method calls, but only a limited set. The following defines a traceable method, identifying only methods that I thought are relevant. It also excludes methods defined in the aspect itself (or in the control flow of the aspect). The latter prevents endless loops from occurring. Let's read this out aloud as well: a traceable method is a method call in a business service (refer to pointcut defined above) while not (and not) in the control flow of an executing advice defined in the FirstFailureDataCapturer and it should also not be a call to equals(), hashCode() or getClass().

Let's use this pointcut to implement the second scenario that we've identified. In the description of the scenario above, we have not specified that we also need to keep track of the current depth. We're using a before advice to log the current call. Let's also use that same advice to keep track of the depth and let's use an after advice to reset the depth to it's previous state.

When an exception occurs inside a business service, register it with the current call context

Now that we're done with the second scenario, we've captured almost all state that we want to capture. The last thing that we wanted to capture was the first exception occurring in the context of that same business service.

A potential failure point is a) an exception escaping from a method or b) an exception handler inside a method (and then wrapped, swallowed, possibly re-thrown, et cetera). Let's use this definition to implement our third scenario. The first pointcut just uses the traceable method pointcut to identify potential failure points. We'll use after throwing advice in a minute to finish part of our scenario. The second is a little more interesting. It defines a pointcut that identifies exception handler (catch blocks) in the control flow of business services. Using this pointcut, we can identify excpetion that are caught, wrapped and re-thrown for example (or caught and swallowed).

We'll use after before and after advice to finish the third scenario. First: before an exception handler, log the exception:

And now, let's define the other advice:

After an exception escapes from a business service, log the current call context

The last thing we need to do is logging the current call context in case a business service execution results in an exception. We already have all the ingredients (the pointcuts) to skip straight on to the advice, so let's go ahead:

Using the CarPlant as an example

In my session at The Spring Experience I used my (infamous) CarPlant example to show the FirstFailureDataCapturer. The CarPlant is a relatively small system that is capable of manufacturing cars. Manufacturing cars is a two-step process: 1) getting parts from a CarPartsInventory system and 2) asking the CarAssemblyLine to assemble the parts into a Car. The CarPlant itself:

The CarPartsInventory in this example is a stub and does not really do anything useful:

The interesting bit here is the CarAssemblyLine. As you can see in the code below, the CarAssemblyLine has some strange code in it. It first throws an exception, catches it itself and then re-throws it as a pretty MeaninglessException.

Obviously, under normal circumstances, the real cause of the problem, the root cause would never be identified in this case (it's caught, not logged… a different exception is thrown and the root cause is not passed along), and we'd also never be able to register the system state exactly at the point the real and first failure (the OnStrikeException) occurred. Fortunately now we have the FirstFailureDataCapturer, we can register the root cause and log it. Below you can find a sequence diagram and some output of a test that I ran. As you can see, we do not just get the call stack, but all calls that occurred in the context of this business service execution, or in other words: the entire call tree.

Capturing system state

If you look carefully, you can see the first exception that is dumped is the MeaninglessException. Right after the MeaninglessException has been dumped however there's a message saying that there is a root cause that's different from the MeaninglessException and then the real exception is dumped. The stack trace also mentions that the real exception was caused at line 18, whereas the MeaninglessException originated at line 20.

Now we have identified the real point where failure occur, we can also start capturing system state. As you can imagine, the system state at CarPlant:18 might differ from the system state at CarPlant:20 and our FirstFailureDataCapturer allows us to register the system state at the correct point in time.

So what is system state anyway? Well, that all depends on the runtime, your specific application and what you are interested in. A couple of examples:

• The currently logged on user
• The current car manufacturing request
• Any technical system state (amount of threads, caching statistics, et cetera)
• The node this exception occurred on

Capturing system state is now very easy and we can do this inside the CallContext.setFirstFailure() method for example.

What about part II??

This aspect is not done yet! The first time the complete aspect came in the picture it was coded up as follows:

As you can see, the call context is instantiated when the FirstFailureDataCapturer is instantiated. The question of course now is: when and how many times will the FirstFailureDataCapturer be instantiated? And, when you've answered this question, another question might come to mind: what happens if this aspect is used in a multi-threaded environment? In the next part I'll discuss all of this and make some other changes to the aspect to polish it a bit. In the meantime, you can always try to answer those questions in the comments of course ! I'll also provide the source code for the aspect in the next part.