Mar 28

Spring 1.2 RC1 Release

Java, Lightweight Containers, Tech No Comments »

The Spring Framework team has done it again ;) Their latest release (1.2 RC1) contains interesting enhancements.

The big guns are:

  • Hibernate 3 support
  • JMX: JMX support for export of Spring beans, annotations, and more.
  • AOP: improved AOP TargetSourceCreator mechanism
  • TX: transaction annotation support for JDK 1.5+

There are also some small items which I am excited about. For one, we now have a short-hand way of defining beans in properties:

<property name=”sessionFactory” ref=”sessionFactory”/>

There is also a lot of talk on using Spring with Jython:

Spring 1.2 RC1 Announcement

Dear Spring community,

It’s Spring time :-)

I’m pleased to announce that Spring 1.2 RC1 has just been released. This release introduces a number of major new features:

* finer-grained distribution jar files, alongside the full spring.jar
* AOP Alliance interfaces are now contained in spring-aop.jar and spring.jar

* XML bean definition improvements (”ref” and “value” shortcut attributes
* improved AOP TargetSourceCreator mechanism (supporting LazyInitTargetSource too)

* transaction annotation support for JDK 1.5+ (annotation called
* improved WebLogicJtaTransactionManager (transaction names, isolation

* SqlRowSet support for JDBC (in conjunction with JdbcTemplate’s
* Hibernate3 support (in orm.hibernate3; Hibernate 2.1 support is still

* JMX support for export of Spring beans as managed resources and for MBean access
* Commons Attributes and JDK 1.5+ annotations for JMX MBean export

This release also contains many minor enhancements, for example:

* factored out BindingErrorProcessor strategy for ServletRequestDataBinder
* improved ParameterMethodNameResolver for Web MVC MultiActionController

For a detailed list of enhancements and bug fixes, see the changelog.

This release candidate is already considered stable and recommended for development use. We expect Spring 1.2 final to be released in late April.

Watch out for the Spring Web Flow preview release to follow later this week (for use with Spring 1.2)! Web Flow will also become part of the nightly build at that time.



Feb 28

Spring 1.1.5 Release

Java, Lightweight Containers, Tech No Comments »

The last in the 1.1.X versions of Spring has been released. Now the Spring team is onto the Hibernate 3 support (good timing), and JMX.

Spring Framework 1.1.5 Announcement

Hi everybody,

I’m pleased to announce that Spring Framework 1.1.5 has just been released.
This is the last bug fix and minor enhancement release in the 1.1.x series, featuring many minor improvements such as:

* added overloaded “reject” and “rejectValue” methods without default message to Errors interface and BindException
* added “lookup(name, requiredType)” convenience method to JndiTemplate, matching the JNDI object against the given type
* added “homeInterface” property to AbstractRemoteSlsbInvokerInterceptor,
for specifying the home interface to narrow to
* introduced MailMessage interface as common interface for SimpleMailMessage and JavaMail MIME messages
* Log4jConfigurer accepts a “classpath:” URL or a “file:” URL as location too, not just a plain file path
* Log4jConfigurer accepts config files that do not reside in the file system, as long as there is no refresh interval

* added “int[] batchUpdate(String[] sql)” method to JdbcTemplate, for executing a group of SQL statements as a batch
* added C3P0NativeJdbcExtractor for C3P0 0.8.5 or later (for earlier C3P0 versions, use SimpleNativeJdbcExtractor)
* added “maxRows” bean property to JdbcTemplate, allowing to specify the maximum number of rows to be fetched
* added “fetchSize” and “maxRows” bean properties to RdbmsOperation, passing the values to the internal JdbcTemplate
* added ClobStringTypeHandler, BlobByteArrayTypeHandler and BlobSerializableTypeHandler for iBATIS SQL Maps 2.0.9
* ResourceHolderSupport throws TransactionTimedOutException if no time-to-live left (before attempting an operation)
* TransactionSynchronization objects can influence their execution order through implementing the Ordered interface
* JtaTransactionManager is able to work with a JTA TransactionManager only (i.e. without a UserTransaction handle)

* upgraded MockHttpServletRequest to Servlet API 2.4 (added getRemotePort, getLocalName, getLocalAddr, getLocalPort)
* upgraded MockPageContext to JSP API 2.0 (added getExpressionEvaluator, getVariableResolver, overloaded include)
* added “contextOverride” option to
ServletContextPropertyPlaceholderConfigurer, letting web.xml override local settings
* added “searchContextAttributes” option to ServletContextPropertyPlaceholderConfigurer, resolving context attributes
* added “clear” and “isEmpty” methods to ModelAndView, allowing to clear the view of a given ModelAndView object
* added JasperReportsMultiFormatView, allowing to specify the output format dynamically via a discriminator in the model
* JSP EL expressions in Spring’s JSP tags will be parsed with JSP 2.0 ExpressionEvaluator on JSP 2.0 (Jakarta JSTL else)
* changed “spring:transform” tag’s “value” attribute from String to Object, to allow for expressions resolved by JSP 2.0

See the changelog for details.

Our next milestone is 1.2 RC1, which we intend to release as soon as
possible: with Hibernate3 support, JMX support and further major new features. Nightly 1.2-dev snapshots with Hibernate3 support and JMX support will be available within a few days, so feel free to give 1.2 an early try


Feb 17

Femtocontainer — The IoC container built into the JDK

Java, Lightweight Containers, Tech 1 Comment »

Sam has wisely seen that Java has a version of IoC via the java.beans.XMLEncoder/XMLDecoder classes.

Take a look at Sam’s XML config:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE javabeans SYSTEM "">
<java version="1.4.2" class="java.beans.XMLDecoder">
<object id="cityFinder" class="com.sampullara.jbioc.CityScape">
<void property="cityMap">
<object class="java.util.HashMap">
<void method="put">
<void method="put">
<object id="region" class="com.sampullara.jbioc.RegionInfo">
<void property="cityFinder"><object idref="cityFinder"/></void>
<void property="regions">
<object class="java.util.ArrayList">
<void method="add"><string>Europe</string></void>
<void method="add"><string>America</string></void>

Now, you may not be a big fan of the Spring XML config, but this is even closer to the bone. It really does shout out “WHY ARE WE USING XML FOR THIS AND NOT JUST CODE!” (especially a dynamic language).

Also, although it does allow some dependency injection, it is basic. It doesn’t support the layers of components/services like HiveMind.

And IoC itself is only part of the picture. The real power of Spring is that it has practical stuff that you can use out of the box! Great find though Sam!

Jan 26

OGNL and Spring

Java, Lightweight Containers, Tech No Comments »

Drew Davidson, of OGNL fame (amongst other), has written an OGNL-based property configurer (BeanFactoryPostProcessor implementor) that evaluates OGNL expressions in <value>, <map> and <list> entries, etc in the Spring configuration.

I get to use OGNL whenever I am working on either of my favourite web frameworks for Java: Tapestry and WebWork2.

It is one of those small languages that does one thing, and does it really well. It is a lot more powerful than the EL.

So, I am excited to see the like of OGNL, and Groovy, for configuring and wiring my components together. Thanks for this work Drew!

Jan 19

Acegi Security Announces Version 0.7

AOP, Java, Lightweight Containers, Security, Tech No Comments »

A fair amount of Adigio projects have taken advantage of Acegi Security instead of container managed security. They just released version 0.7.

Dear Spring Community

I’m pleased to announce the Acegi Security System for Spring release 0.7.0 is now available from The project provides comprehensive security services for The Spring Framework. You can read about the features in detail at

There are many changes, improvements and fixes in release 0.7.0 (as listed at The major new feature areas are:

* Significant improvements to ACL security services
* AspectJ support (useful for instance-level security)
* Refactoring of ObjectDefinitionSources (especially useful for web URI
* Automatic propagation of security identity via RMI and HttpInvoker
* Integration with Servlet Spec’s getRemoteUser()
* Refactoring of Contacts sample to use the new ACL security services
* Additional event publishing (now includes authorisation, not just
* CVS restructure to use Maven as the build system
* A new project web site with FAQs, links to external articles etc

The new ACL security services deserve special mention, as they make it possible to develop applications that require complex instance-based security without any custom code. The entire configuration of such applications can be declared in the IoC container using standard Acegi Security services, so this should help significantly improve architecture and development time.

As per the Apache APR project versioning guidelines, this is a major release. We expect the next major release will be 1.0.0, although release 0.7.0 should be considered stable enough for most projects to use. There are detailed upgrade instructions included in the release ZIP and on the Acegi Security home page.

For Maven users, Acegi Security’s latest JARs are available from We will also be adding release 0.7.0 and above to iBiblio.

We hope you find this new release useful in your projects.

Best regards

Dec 17


EJB, Java, Lightweight Containers, Tech 6 Comments »

After hearing more about EJB 3, and talking to various people, why are we putting dependency Injection semantics in an EJB spec?

I can see one reason: “Let’s just get EJB 3 done”

This is a reason for not splitting the persistence API into a truly seperate JSR (although it IS mean to be a seperate spec/tck/runtime).

Dependency injection is a very generic concern, and one that should be shared throughout a bunch of specs. One tiny JSR could flush out the semantics
of dependency injection, and end up with javax.dependency.*.

Then EJB 3 would specify that “When you @Inject a transaction manager…. you must do X”. A future Servlet spec could do the same thing for their resources, etc etc.

Also, lightweight containers would have the option of groking these annotations too, without needing some ejb.jar.

Wouldn’t that be nice?

Oct 04

Lightweight containers vs. EJB: Don Box, Ted Neward, Rod Johnson, and more

EJB, Java, Lightweight Containers, Tech 9 Comments »

A blog discussion has started on the subject of lightweight containers, and somehow changed to OR mappers at the end :)

Neward on Crupi

What is the state of the enterprise Java world, anyway?

I think there are some KEY differences with the recent move to lightweight containers.

The various tools that I seem to prefer these days have one thing in common:


I think this is a huge thing. I think that so many projects have gotten away from core OO practices (and OO doesn’t mean distributed objects Ted!) because they were stuck with crappy EJBs. These applications were built using “patterns” of:

Stateless Session Bean – Entity Beans – which use DTOs

This isn’t OO. This is RPC. The entity beans often had simple mapping, and don’t allow for inheritence. DTOs are evil as they are a duplicate layer of structs that you are throwing around.

Note that I am talking about an application that isn’t a service. I am talking about building an internal application first, using good OO practices, and THEN you can lay on the service layer to allow for external stuff.

So, back to transparency.

IoC Containers

I can finally write code that is just POJO based. There are no extension points to the framework. I am not stuck extended evil EJB interfaces and classes, having to create “home” interfaces and such. This all gets in the way. Not only does it get in the way but not I am totally tied up in knots.

With a container like Spring you look at my code and would have no idea if I am using it! What if I want to move to something else like Pico or Hivemind? I can. My core business logic is in tact and I can go about my way of moving. I don’t sit around crying because I have to munge my logic from the coupling with the framework! I love it.

JDO, Hibernate, etc

I like transparent persistence (not that it is truly transparent due to the OO-DB mismatch… but it gets close). Once again, I can develop a full, rich, domain object model. The model can even have inheritence and interfaces, and maybe people will put in real business methods that do things instead of just gets and sets (gasp!).

Now with a marriage of these technologies I have a clean domain object model (transparent persistence), and clean services (lightweight container). Testing IS a lot nicer too in my experience Ted. You don’t need to run around finding or building bloody mocks for the environment.


I do agree with Ted in that EJB is good for some things, such as 2PC and Message Driven Beans. There is going to be a kick arse way to do MDB in Spring coming up soon, so that need will go away. What about 2PC?

Well, a couple of things can happen:

a) The lightweight container can support them
b) You use an EJB when you need to do 2PC! One nice thing about the lightweight containers is that they can be used WITH EJB too :) However, HOW many applications need 2PC? 2%? And then within those applications, how many of their transactions need to be 2PC?

If you can’t see that Spring isn’t nicer than EJB? Ouch. You must like eating the elephant ;)

Aug 05

RE: Lightweight Containers vs. EJB3

EJB, Java, Lightweight Containers, Tech No Comments »

Merrick has a nicely thought out critique at Lightweight Containers in comparison to EJB 3.

His basic premise is that EJB 3 fills the gap of the lightweight containers. Although I think it is a great step forward, I think there are a few areas which worry me:

What are we specifying?

I would personally love the expert group to be able to step back and think about what EJB is all about. Where is the “E”, and what should be spec’d?

In my humble opinion, I think that the EJB spec should be a pretty lean one, that acts like the J2EE spec… in that it offers the programming model + integration hooks into other specs. The other specs are basically out there to define the cross-cutting enterprise services, and could later have AOP info.

The obvious example is persistence. Get a new spec for that if you really can’t stomach talking to JDO people. But get it external, and have it for EVERYONE.

There are also many other examples. Security, worker threads, blah blah.

Backwards compatibility requirements

I understand backwards compatibility is good. However, I think it is OK to make some things optional. Having all of the EJB 2.x and below baggage is painful for some people (e.g. Spring) and keeps them out of the loop. Make it optional, and if you ARE backwards compatible you can get a shiny checkbox. Then, if a company gives a monkeys they can get an implementation that has the shiny star.


In some of the open source projects such as Spring, there is an air of inclusion. What do you want to do for persistence? JDO? Hibernate? iBATIS? We will hook in and help you out with all of them.

You don’t feel that same way with the EJB vendors. The feeling is more like “Oh man, they want to hook us into their damn EJB CMP engine that we can’t bloody swap out as the PersistenceManager STILL isn’t pluggable after all these years”.

Come on guys, let’s play nice. You can still compete on features / QoS / etc.

So, although I am excited about EJB 3…. I want more :)

Aug 02

NanoWeb: PicoContainer + Groovy = no XML again?

Groovy, Java, Lightweight Containers, Tech, Web Frameworks No Comments »

Here we have another one in the “get me away from angle brackets” category.

Kris Thompson pointed to the Nice clean, dynamic MVC framework: NanoWeb.

NanoWeb is a simple and powerful dynamic MVC framework based on Java servlet technology,Groovy and NanoContainer. NanoWeb borrows many ideas from WebWork and Struts, most importantly the concepts of actions and views. Its main difference from these frameworks is that it is 100% dynamic and requires no configuration beyond mapping of to servlets in web.xml

Pelle Braendgaard wrote a nice introduction to NanoWeb, in which he walks you through a simple application.

I liked his quote after writing the Groovy action:

I am no Groovy expert. As a matter of fact this was my first attempt at groovy and I have no idea what I

Jul 30

Springing forward with Groovy

Groovy, Lightweight Containers, Tech 2 Comments »

We have really been enjoying writing WebWork actions in Groovy. It is a pleasure, and I had a really nice chat with Rod Johnson about how cool it would be to write beans for Spring in Groovy.

Rod then managed to whip up some code that lets this happen, so you could do:

<bean id=”property”
<constructor-arg index=”0″><value>org/springframework/beans/groovy/PropertyHello.groovy</value></constructor-arg>

<!– Reload seconds –>
<constructor-arg index=”1″><value>20</value></constructor-arg>

<!– Property on created Groovy object –>
<property name=”message”><value>hello world property</value></property>

Works like a charm :)

We also talked about maybe allowing other languages to be plugged in. Imagine a config such as:

<bean id=”something”>
<script language=”groovy” file=”org/springframework/beans/groovy/PropertyHello.groovy” />

<property name=”reloadSecs”><value>20</value></property>

<property name=”someDI”><ref bean=”SomeBean”/></property>

We also talked a little about having Groovy as a config option, and at then Bing Ran emailed the groovy-dev list with a concrete example of how it would look:

import org.springframework.jndi.JndiObjectFactoryBean
import org.springframework.orm.hibernate.LocalSessionFactoryBean
import net.sf.hibernate.dialect.MySQLDialect
import org.apache.commons.dbcp.BasicDataSource
import product.ProductDaoImpl

DataSource myDataSource = new JndiObjectFactoryBean {
jndiName = “java:comp/env/jdbc/myds”

DataSource myDataSource2 = new BasicDataSource(”destroy-method”:”close”) {
driverClassName = “org.hsqldb.jdbcDriver”
url = “jdbc:hsqldb:hsql://localhost:9001″
username = “sa”
password = “”

SessionFactory mySessionFactory = new LocalSessionFactoryBean {
mappingResources = ["product.hbm.xml"]
hibernateProperties = [hibernate.dialect : MySQLDialect.class]
dataSource = myDataSource2

Dao myProductDao = new ProductDaoImpl {
sessionFactory = mySessionFactory

The general idea is to use a constructor like structure to describe the wiring of objects.

1. implicit property setting: since we know that an assignment in the Groovy constructor call is to set the property, we save <property> pair, my mind doesn’t need to use any extra energy to interpret it.

2. better list/handling. Groovy list/map construct really shines here, instead of saying:

<property name=”mappingResources”>

I used:

mappingResources = ["product.hbm.xml", "customer.hbm.xml"]

Instead of:

<property name=”hibernateProperties”>
<prop key=”hibernate.dialect”>net.sf.hibernate.dialect.MySQLDialect</prop>
<prop key=”hibernate.someotherkey”>some other value</prop>

I did:

hibernateProperties = [
"hibernate.dialect" : MySQLDialect.class,
"hibernate.someotherkey" : "some other value"

3. Possible strong type checking: the interpreter, when compile the groovy config , can check if the property settings is match the types. In the xml file, everything is just a bean, and I have to read the class name to “infer” what type of beans they are: a data source, transaction manager, a DAO, an Interceptor, etc. This makes reading the config quite a whirl.

4. Possible tree like structure: instead of:

<bean id=”myHibernateInterceptor” class=”org.springframework.orm.hibernate.HibernateInterceptor”>
<property name=”sessionFactory”>
<ref bean=”mySessionFactory”/>

<bean id=”myProductDaoTarget” class=”product.ProductDaoImpl”>
<property name=”sessionFactory”>
<ref bean=”mySessionFactory”/>

<bean id=”myProductDao” class=”org.springframework.aop.framework.ProxyFactoryBean”>
<property name=”proxyInterfaces”>
<property name=”interceptorNames”>

I can do something like this:

ProxyFactory myProductDaoFactory = new org.springframework.aop.framework.ProxyFactoryBean {
proxyInterfaces = product.ProductDao.class
interceptors = [
new HibernateInterceptor {sessionFactory = mySessionFactory},
new product.ProductDaoImpl {sessionFactory = mySessionFactory}

After we have macros in Groovy we can build configurations that configure huge number of otherwise similarly configured beans such as DAOs:

#def_dao ["dao1", dao1Impl]

#def_dao ["dao2", dao2Impl]

#def_dao ["dao3", dao3Impl]

#def_dao ["dao4", dao4Impl]

The possibility is unlimited.

Now, a good binding of Groovy will not only simplify the config, but probably more importantly, simplify writing Spring beans.

Here is an example:

public class ProductDaoImpl implements ProductDao {
private SessionFactory sessionFactory;
public void setSessionFactory(SessionFactory sessionFactory) {
this.sessionFactory = sessionFactory;
public List loadProductsByCategory(final String category) {
HibernateTemplate hibernateTemplate = new HibernateTemplate(this.sessionFactory);
return (List) hibernateTemplate.execute(
new HibernateCallback() {
public Object doInHibernate(Session session) throws HibernateException {
List result = session.find(”from test.Product product where product.category=?”, category, Hibernate.STRING);
return result;

Here is the same Dao impl in Groovy:

class ProductDaoImpl implements ProductDao {
property SessionFactory sessionFactory;

List loadProductsByCategory(String category) {
ht = new HibernateTemplate(sessionFactory);
return ht.execute {|session|
session.find(”from test.Product product where product.category= ${category} “)

The property and the Closure features make it look a lot cleaner. Groovy could well suited to writing Spring beans: each unit is small and clearly intended. We don’t need too much compiler help to make it work and there is no compile and deploy cycle.

Further down the road, I imagine that macros/annotations can help us build a groovy data access layer that sits on top of the Spring JDBC templates to implement a mean and clean persistent mechanism: no XML mapping files, auto-interfacing (defining the interfaces and impls in the same file), etc.. Would that be cool?

Now we have a strong use case for Groovy!


All early days, but cool :)