Java Bien!

I love Spring Framework. I use it on almost every project and I’m pretty close to think that I couldn’t leave without it. However, lots of people really dislike it for plenty of reasons. This makes me wonder what are the real flaws I would name.

The first flaw that comes to my mind is the documentation.

Really? When giving training on Spring for Valtech, I’d always tell trainees that the documentation was very well done. In fact it is. But, it is pretty outdated. Not for its content but for the way it considers xml as the primary configuration paradigm all the way through (well, not for aspects).

Xml DSLs are verbose, lack serious static checking and, let’s be honest, XML wasn’t really made to do this kind of things.

Spring has been able to use other configuration paradigms (none, plain java, annotations, JavaConfig…) for a long time but this is very often considered secondary options.

Maybe Spring 3 will change this by sort of “deprecating” xml configuration. I’m just afraid that annotations will be the new primary configuration paradigm that we’ll complain about in the coming years.

Speaking about documentation, another flaw is the bias towards plain JavaBeans. Spring is really pushing a POJO approach but people understand pure JavaBeans. With default constructor, getters and setters…

This was not Spring’s original intent and, believe me it it still very powerful in integrating frameworks not based on JavaBeans (ever tried Joram?). But reading the documentation, the borders between POJO (ie. any Java object that you can write) and JavaBeans (overused silly reflectable properties wrappers) tend to blur. Why did they use the name Spring beans? I think it was to show the lightweight approach compared to Enterprise Java Beans. But now that EJBs are dead in the form we used to know, people think Spring is pushing a design based on JavaBeans specification. Change the documentation please!

What do you think? Please no bashing!

Other flaws coming in future articles…

In my previous post, I compared Guice and Spring JavaConfig. The conclusion is that, for my application, Spring is much easier to use and less verbose. However, the major force of Guice I didn’t talk about is it’s ability to inject Singletons into large applications in a very (very) effective way.
Read more…

Today, I’ve had the opportunity to test Guice on a real project. I must say that the developers really pushed the idea of statically typed IoC very far.
Read more…

Googling for ways to integrate GWT with Spring, I didn’t find any simple solution.

Here is what I need :

• GWT RPC services should be Spring beans.
• They should be POJOs NOT extending RemoteServiceServlet.
• Mapping between Servlet paths and beans should be straightforward.

Here is what I came up with :

• It’s a very simple Servlet that receives every RPC request.
• It then gets a Spring bean by the name of the Servlet path used for the call.
• The method call to the bean is done with reflection.

public class SpringDispatchService extends RemoteServiceServlet {
    private final ClassPathXmlApplicationContext context;

    public SpringDispatchServiceImpl() {
        context=new ClassPathXmlApplicationContext(“beans.xml”);
    }

    public String processCall(String payload)
        throws SerializationException {
        try {
            Object target=context.getBean(getServletName());

            RPCRequest rpcRequest=RPC.decodeRequest(
                payload,target.getClass());
            
            Method method=rpcRequest.getMethod();
            Object[] params=rpcRequest.getParameters();

            Object result=method.invoke(target,params);
            
            return RPC.encodeResponseForSuccess(method,result);
        } catch(Throwable ex) {
            return RPC.encodeResponseForFailure(null,ex);
        }
    }
}

Spring supporte déjà le standard JPA des EJB3. Le projet Pichfork d’Interface21 vie à apporter le support complet des EJB3 à travers le support des annotations standard JEE5. Ce projet servira de base au futur Weblogic.