There were two presentations about new functionality in Spring at JavaPolis 2006. I took a few notes on them.
Spring OSGi by Costin Leau
The Open Services Gateway Initiative (OSGi) is a component management framework, with flexible version management and support for runtime changes to the components. Some of the features of OSGi are:
- version and dependency declaration in a JAR's manifest file
- dependency declarations include version specifications
- support multiple versions of the same library in the same container
- load, unload and replace modules at runtime.
The terminology used in OSGi for modules is bundles, but I'll use the terms bundles, components and modules interchangeably.
The modules themselves are of two types:
- Passive modules, which export Java classes directly. A client module which depends on a passive module loads the module's classes into its classloader. This means that changes to passive modules are only visible to client modules loaded after the change, or when a client module is refreshed.
- Active modules, which publish proxy services for their Java classes. A client module which depends on an active module makes calls through the service interface. This means that changes to an active module are available immediately to all client modules.
The module types form an interesting distinction, but there wasn't much more made of it. Active modules seem far superior, so I'm not sure why passive modules are ever used.
Spring comes in by supporting OSGi bundles as a built-in bean type. The OsbiBundleApplicationContext allows bundles to be loaded from the OSGi platform and used as if they were normal Spring beans.
Spring itself can even be bootstrapped from OSGi. Simply include the spring-osgi JAR file in your classpath, create a bundle context, and the necessary Spring dependencies will be retrieved from OSGi as well.
The Spring integration also includes listener interfaces for being alerted to OSGi events. Listeners can monitor the addition or removal of OSGi bundles.
Module identity and dependency information for OSGi are declared in a JAR's manifest file. The dependency information is two attributes: a list of Java packages that it requires (imports), and a list of packages that it exports.
Costin gave a demonstration at the end of an OSGi platform running inside an applet. The applet showed the packages currently installed, and he could use a simple Swing application with a single dependency to show how the code could quickly be refreshed to change the behaviour of the Swing application at runtime.
My big concern with all this was how it would work inside a web application container. Typically, there are an array of servlets which perform actions for various URL patterns, then servlet filters and listeners, and so on. However, when asked about this important issue, Costin didn't give a convincing answer. He answered something completely unrelated, as far as I could tell, about the dependencies of OSGi itself.
I suppose similarly to Spring itself, the OSGi platform could be brought up by a context listener, and your servlets would delegate business logic to the OSGi-bundled Spring beans. I can't really see a method whereby the servlets themselves or the URLs they handle could be OSGi bundles or configuration therein.
Spring 2 update by Rod Johnson
Goals of Spring 2 were simple: maintain backward compatibility and continue to realise the goals of simplicity and power.
Annotations for transactions have been supported since Spring 1.2, but the new release simplifies the XML configuration by using XML namespaces. For example:
<tx:annotation-driven/> <aop:aspect-autoproxy/>
The first line above enables annotation-driven transactions for all beans with the appropriate class annotation. The second enables aspect annotations, which are new in Spring 2.
Aspects seem to be unnecessary to many programmers, but Rod asserts that they're not. When you think about cross-cutting concerns in an enterprise application, you can come up with good examples like:
- service layer operations should be transactional
- data access operations that throw SQLExceptions should be wrapped.
Spring 2 allows powerful AOP functionality by allowing AspectJ pointcut declarations in the Spring context, then referencing those pointcuts in the code with annotations. Apparently with these two technologies, you'll be able to easily implement aspects like the two above.
Spring has been used in some high-throughput transactional systems, and Rod gave some examples of this.
For 2007, one of the main goals of the framework is to integrate OSGi.
Overall, an interesting presentation with some appealing ideas to explore further.
