Spring dm Server Considered Cool?

w-jax is over...

I'm just returning from w-jax 2009, one of the biggest german Java conferences, covering every technology related to Java actually.

If there are any hypes this year, they are these: Scala, Cloud Computing and OSGi. And, of course, Spring – which is all around.

Spring Source employs a lot of brave guys, and hearing first-hand about their newest coolest technologies is always refreshing. Did you know that Tomcat is to a large extent pushed by guys paid by Spring Source? I forgot the exact number, but Eberhard Wolff said the majority of bug fixes and commits is done by Spring Source's Tomcat team.

Spring dm Server is Cool!

There have been some sessions about Spring dm Server, and when taking a closer look it seems to be clear why Spring Source invests in Tomcat that much. Spring dm server is based on Tomcat, and they add the ability to deploy web application modules as OSGi bundles. This way, you can partition your web apps into separate bundles to deploy them independantly and dynamically into the server. Yes, they are preserving OSGi's dynamic, meaning that you can stop, start or refresh a particular bundle without the need to stop and restart the server. As you would expect, other bundles continue to work. If a requested OSGi service is temporarily not available, dm Server will wait 5 minutes for it being redeployed.

Spring dm server is part of Spring Tool Suite, an Eclipse based development environment which is also able to auto-deploy a module whenever it changes.

All of this is quite gorgeous from a technical perspective, and the Spring guys had to cope with some really hard issues (for instance, realted to JPA where they need an application wide visiblity of bundles as well as load time weaving – you won't want to know the details...).

Really? What for?

But... is this really of any interest in the field?

Our customers are using WebSphere (or WebLogic or maybe JBoss) application server, and all of them are not capable of running such a modularized, OSGi based application. Moreover, in a production environment, there is no need and most often it is actually not even desired to be able to refresh application bundles dynamically.

So, what's left? Modularizing your application? Right, that is leading to a better structure and less coupling and blah blah, but the same can be achieved without OSGi (just let the business domain drive your application "slices"). It's just that you are forced to use modules (bundles) when you are using OSGi.

If at all, Spring dm server will pay off for developers since it may speed up development (especially the build-deploy-test cycle). But is this really, I mean really, hurting us that much? Hence, if you were asking me, a lot of technical overhead and server lock-in for no real benefit.

So, will Spring dm server be able to gain real attention, I mean beyond being technically cool? I'm sceptical. As always, time will tell...

Spring: Use Custom Namespaces!

Have you ever heard of custom XML namespaces for Spring? I know you love Spring (like I do), so... probably yes. They are available since Spring 2.0 which came out October 2006, so I just can't believe we didn't use them up to now.

The Old-Fashioned Way

Well, we are building our web apps on JSF and Spring Web Flow, and additionally use a custom framework for adding a few more features like mapping between business objects and view objects based on XML mapping descriptions. Of course, this framework part is designed "IoC friendly", i.e. it's based on interfaces and standard implementations that need to be plugged by Spring configuration.

We did this by providing a basic Spring configuration that defines defaults for most elements and injects all required references into the main configuration objects. To allow the project to provide custom implementations, this code relies on particular bean names that have to be defined by the custom project. Here's a simple example for the framework's configuration:

<bean id="iplIntegrationInfo" class="...IntegrationInfo">
  <!-- myViewObjAccessor: to be defined in project specific Spring config file -->
  <property name="viewObjAccessor" ref="myViewObjAccessor" />
  <!-- myContextResolver: to be defined in project specific Spring config file -->
  <property name="contextResolver" ref="myContextResolver" />
  ...
</bean>

<!-- These can be used for aliases if standard implementation should be used -->
<bean id="defaultViewObjAccessor" class="..." />
<bean id="defaultContextResolver" class="..." />

As you can see, all references are injected into the main configuration (iplIntegrationInfo). However, the referenced beans are not actually defined but have to be provided by the project. So, here's an example for the project's configuration:

<!-- use default -->
<alias alias="myViewObjAccessor" name="defaultViewObjAccessor" />

<!-- use custom implementation -->
<bean id="myContextResolver" class="..." />

Here we use the default for the first bean (by just establishing an alias for the configuration done in the framework file), and a custom implementation for the second.

This approach works, but obviously has a few drawbacks:

• Configuration is shared between framework and project specific configuration code.
• Project needs to know the framework's Spring file to do its work.
• Internal framework structures (bean names, classes) are exposed to the outside.
• A lot of XML code is required, even if using all the defaults.

Using Custom Namespaces

What should I say, we have switched to custom namespace lately and now configuration looks like this:

<ui:view-config/>

That's as short as it can be, but still is a complete configuration in case the project is using default implementations for all the beans. If the project would like to override some settings, the configuration file may be:

<ui:view-config>
  <ui:viewobj-accessor ref="viewObjAccessor"/>
  <ui:context-resolver ref="contextResolver"/>
</ui:view-config>

<bean id="viewObjAccessor" class="..." />
<bean id="contextResolver" class="..." />

Hence, you have the option to override all default implementations, and use meaningful tags to do so. Can you see the gains?

How Does This Magic Work?

I'm not going to provide full description on how to author custom namespaces since that is available in the Spring reference documentation and elsewhere. So, just a few basics to give you the idea...

First of all, you have to provide an XML schema describing your namespace. Then you have to implement a Namespace Handler that links each tag of your namespace to an XML parser, the Bean Definition Parser. And then, of course, those parsers must be implemented.

Each bean defintion parser is supposed to parse the XML element (including all attributes and sub elements) and to build the appropriate Spring beans. Spring provides a small hierarchy of classes you can use, depending on your situation:

• The most specific is AbstractSimpleBeanDefinitionParser that fits well when there is a strong correlation between the attributes on a tag and the properties on your bean. In this case, there is really few code on your side.
• The AbstractSingleBeanDefinitionParser is a bit more general, it allows you to create any single bean definition for an arbitrary complex nested XML structure. This involves more coding, of course, but still does some work for you (like automatically registering the bean in the context). This is the one you'll probably use most of the time.
• The AbstractBeanDefinitionParser is even more general and allows you to create multiple bean definitions and register them directly. It takes care of id generation and a few other things.
• Instead of using the latter one, you could also implement the BeanDefinitionParser interface directly, giving you all the flexibility you need.

All in all, you'll need a few hours to get comfortable with all the classes that are used to build up the bean definitions (DomUtils, BeanDefinition, BeanDefinitionBuilder, RuntimeBeanReference and ManagedMap/ManagedList to name a few).

But after that, building the parser and creating/registering your beans is quite straightforward. Moreover, you always can sneak a peek on how Spring itself is doing it for the Spring provided custom namespaces (like for Spring Security, for instance).

Okay, that's all for now, so go ahead and make life easier for your customers, your team, or yourself by providing a well-designed custom Spring namespace!

Spring: Test Framework Never Heard of Web Apps?

Do you know the Spring TestContext Framework? You really should. It drastically simplifies JUnit-testing of Spring powered applications. One particular cool thing is that it offers an easy, annotation based way to load your Spring context and auto-wire your beans. For example, this is how it could look like for JUnit 4:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = "classpath:spring-config/ui-test-config.xml")
public class MyParticularTest {
  @Autowired
  private Controller controller;
  ...
}

This is really nice, but... there is one thing we stumbled upon lately.

The test framework by default is using the GenericXmlContextLoader which loads the Spring application context as an instance of GenericApplicationContext. This class, obviously, is not aware of web applications that would require a WebApplicationContext instead. Hence, you can't access any web related resources, use associated scopes etc.

Don't get me wrong... Spring TestContext Framework is nice, but it's more than strange that it does not support the web scenario. There is a Jira issue for that, but it's still open for more than 10 months now, and is scheduled not until Spring 3.1?!? That's just annoying.

Well, there are some workarounds of course, based on using a custom context loader. See this blog post or this Spring community thread, for instance.

Spring Web Flow: watch out!

Starting in November 2008, we found a concurrency issue in our web applications that are based on the following framework stack:

• Spring 2.5.4
• Spring Web Flow 2.0.5
• JSF 1.2_09
• Facelets 1.1.14a
• Trinidad 1.2.9

The issue

For a single user, everything run fine. However, when multiple users hit the application, we got some strange exceptions occasionally – not always and not always at the same place. However, we managed to get this one regularly with our JMeter tests:

SCHWERWIEGEND: Error Rendering View[/plan/FindPlan.xhtml]
javax.el.PropertyNotFoundException: /file:/.../facelets/ipl-comboBox.xhtml @64,30 value="#{localField.jsfValue}": Target Unreachable, identifier 'localField' resolved to null
at com.sun.facelets.el.TagValueExpression.getType(Tag ValueExpression.java:62)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.ValueRenderer.getDefaultConverter(ValueRend erer.java:78)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleSelectOneRenderer.renderNonElementCon tent(SimpleSelectOneRenderer.java:323)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.FormElementRenderer.encodeAllAsNonElement(F ormElementRenderer.java:172)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.FormElementRenderer.encodeAll(FormElementRe nderer.java:105)
at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:335)
....

This exception got rendered on the page instead of the actual component. At other times, we got java.lang.IllegalStateException and other funny behavior.

The strange thing is, the referenced variable is put into the flow scope, of course. Now that we took the time to debug into this issue, we can see that the scopes seem to be correctly filled and the property is actually there, it's just that the ELResolvers could not retrieve it...

Actually, we thought it would be caused by our Java or Spring configuration code, presumably using wrong bean scope or the like.

...is fixed!

Guess what... now I have been pointed to this bug of Spring Web Flow version 2.0.5: Class SimpleELContext is not thread-safe, but is stored in some application singletons :-( See this or this thread for more details.

The good news is, the bug is fixed in version 2.0.6; we have upgraded our projects and load tested them, and everything is just fine.

But...

IMO this is leaving a stale aftertaste. I'll tell you why.

That issue is a severe one: web applications using SWF 2.0.5 are just not working for concurrent users. Everybody using SWF in this version (maybe earlier versions as well) is affected. Given that, it seems strange that

• the issue hasn't been reported and fixed earlier: Version 2.0.5 has been published on 14th of November, and it took more than 2 weeks for the Jira issue to show up.
• this issue is hard to find in the web: Of course, we did some web research to find out if someone else might have a similar problem, but we did not find very much useful. The mentioned threads have started in February/March 2009 – did nobody suffer from this bug earlier than that? Why did nobody post this issue anywhere before?
• the fact that this version is buggy hasn't been reported on Spring Source web pages: Since it's rather threatening, why not put an eye-catcher message on the download page (or somewhere else) telling that this version is buggy and should not be used?

I can see two reasons for this situation, and actually I don't like both: on one hand, there seems to be no load testing by Spring Web Flow team before doing a release; on the other hand, this version 2.0.5 is probably not used very much for real-world web applications by the community out there, and I honestly hope that this is not true to SWF as a whole...