It all started when I needed to start the Transaction out in the view, i.e. as soon as the resource is opened on the HTTP side (rather than when the database service layer is called). I’m using JPA for a number of reasons;

1. I need to access multiple databases each with a different schema (this means different connections)
2. They need to have XA transactions.
3. I’d like the transactions managed by the container (JTA).

JPA provides all these things easily without all the complex Hibernate.xbm.xml mapping files and what-have-you.

The trick to starting the transaction with the web session is to use spring’s OpenEntityManagerInViewFilter. Unfortunately I was using  PersistenceAnnotationBeanPostProcessor to manage my multiple persistence units. The filter wants to know what EntityManagerFactory it should bind to, and fair enough. But with my minimal configuration, there was no addressable EntityManagerFactory!

The solution was to stop the PersistenceAnnotationBeanPostProcessor from doing the JNDI look ups and bind each PersistenceUnit into the Spring context with a manual JNDI lookup;

  <tx:annotation-driven />
  <tx:jta-transaction-manager />

  <bean id="pabpp" 
   class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor" />

  <jee:jndi-lookup id="onePU" jndi-name="persistence/onePU" />
  <jee:jndi-lookup id="twoPU" jndi-name="persistence/twoPU" />
  <jee:jndi-lookup id="threePU" jndi-name="persistence/threePU" />

then, in the web.xml the ViewFilter could be bound explicitly to the required persistence unit, in this case “onePU”. A fuller explanation can be found on my spring source forum post here; http://forum.springsource.org/showthread.php?115844-OpenEntityManagerInViewFilter-with-JPA-PersistenceAnnotationBeanPostProcessor

Overall, this is now quite an elegant solution.

UPDATE. More documentation of the solution and the various configurations at the Spring forum here: http://forum.springsource.org/showthread.php?115587-Example-for-using-two-databases-w-Spring-amp-JTA-transaction-manager&p=383432#post383432

For a start, the documentation is merely a series of outlines of brief hints. One measly section.The laughably short Spring 3 doco section 13.5.1.4 “Dealing with multiple persistence units” conveniently omits  the transaction manager configuration from the example. The problem appears to be that the JPA transaction manager only (and compulsorily) deals with one entity manager factory. And an entity manager factory only deals with one persistence unit. So therefore you have to have two JPA transaction managers. Which means the two persistence unit transactions won’t co-operate properly even though they may share the underlying datasource and are configured through the single persistence unit manager bean.

The above scenario is totally trivial in an EJB 3 container backed with Hibernate, or Eclipselink, as the provider. About one-quarter of the configuration. If I have to use a JTA transaction manager obtained by JNDI lookup from the container, to run a transaction across two JPA persistence units which share the same underlying datasource, why the hell am I using Spring in the first place?

All I wanted was to isolate one set of db transactions from another, use JPA persistence units so the two sets of tables could live easily in two different schemas, and use the annotations to kill the fragile AOP regex-like-but-not-like-regex class and method pattern-matching jiggery pokery from the Spring configuration.

My god, this is such a stonkingly non-trivial forest of horrible configuration and a trial and error morass of filthy swamp miasma … an equivalent EJB3 backed by Hibernate JPA set up is, by comparison, an almost effortless task. I can produce a unit-tested all singing all dancing multiple persistence unit JPA app running in an EJB 3 container with XA datasources using Hibernate as the JPA implementation in almost no time at all. Getting the same thing with Spring (oh, and running some tests with Jetty inside Maven) is like having all your teeth pulled while you’re coming down from a three day methamphetamine binge. Getting Spring to run with multiple JPA persistence units on the same JDBC connection (without XA, across the same database connection) with a transaction propagation of REQUIRES_NEW on the entry point of one of the units is a hair-pulling, beard-greying, head-desk banging, co-worker punching, drunken ranting, blood-pressure raising experience of pure horror. Which apparently doesn’t end.

Die, Spring, die. Can’t come soon enough as far as I am concerned. It’s more evil than Oracle. At least you know with Oracle you’re in for an un-lubed hard and fast backdoor job from Ellison with no reach-around before you even unpack the box. Spring is like a beautiful young sexy soft-porn film that turns into some relentlessly horrific succubus-filled horror film half way through.

Seriously, its enough to make one pine for bloody Weblogic. Spring is the new EJB 2.1.

There is a web service inside a component, let’s call that component a ‘Node’, that receives something like (but not identical to!) an Event on its interface. Inside the Event is some data that the Node does not particularly care about (and actually has no access to – it’s just a byte[] as far as the Node can tell). However, the Node contains a Registry which enables components, lets call them Event Handlers, to register themselves with the Node, as available to process certain Events (i.e. decode that byte[] and do something with it) according to criteria which the EventHandler injects into the Node’s Registry.  EventHandler is an interface with a handful of simple methods related to handling the Event, and also registration with the Registry.

So, the process flow looks something like this: The Node first records the reception of the Event at the interface in a log. Then it tells the Registry about the Event, and the Registry produces the EventHandler(s) it needs to use.  The Registry gives the Node back the instances of the EventHandler interface. The Node then hands off the Event to the EventHandler, which does whatever it does unbeknownst to the Node, and returns a fairly simple EventResponse object. The Node records the EventResponse object in its log (i.e. a database) and returns it as the response to the web service call.

Consider the Node service method as looking something like this (you’ll have to excuse the Java 1.4-ness of this code, the WordPress code highlighting plugin apparently hates Java 5) :

  public List receive(Event event) {
    List responses = new ArrayList();
    for (EventHandler handler : this.registry.lookup(event.getMetadata())) {
      Response response = handler.handle(event);
      saveResponse(response, event, handler);
      responses.add(response);
    }
    return responses;
  }

To enable the wiring, the Registry has a method:

  void register(EventMetadata metadata, EventHandler handler)

and among other methods the EventHandler interface defines:

  void setRegistry(Registry registry)

Currently the WAR file imports the Node.JAR and a group of EventHandler.JAR files which are specific implementations for handling different kinds of Events. We configure it in Spring currently so that the specific EventHandler is injected with the Registry object (from the Node.JAR). The EventHandler implementation then registers itself with the Registry in a call-back operation, telling it what sort of Events it will handle.

This all works just fine at the moment. The problem with what we have is that it is all currently statically compiled into the WAR file.The WAR file specifies a Spring application context XML file which in turn loads the Spring configuration for the Node and Registry component, and every Spring application context for each Handler JAR included inside the WAR file’s WEB-INF/lib directory.

Now, we now don’t want every deployed instance of every Node to handle every possible Event. Currently we’ve got a small .properties file that actually tells another Spring component which EventHandlers are be to be instantiated or not. This is working fine when we only desire some Nodes to handle maybe one or two of a larger group of related Events. That is, where we currently don’t mind that the WAR file is identical in every respect on every Node — it’s just that each node contains a .properties file in its classpath that tells it which EventHandlers it is allowed to load and use (and therefore what Events it is capable of receiving, bearing in mind that when I say ‘Events’ there is really only one concrete type of Event, I mean the encrypted data which is held within the Event which is actually consumed by the Handler).

However, we are now in a situation where we want to use this same architecture for a completely different group of Events. We definitely don’t want to have to compile and assemble a new WAR file for different Nodes based on the Event cluster. We want to deploy a standardized Node.WAR which has available on its classpath a dynamic set of XxxEventHandler.JAR which can dynamically register themselves with the Node’s registry. There may be also a requirement for some related custom extension points in the future.

Initially we considered OSGi as the technology to enable this. After some discussion yesterday with people who know better about OSGi, this approach was rejected as impractical for the moment. Therefore last night I set out tooling about with the Spring 2.5.6 ApplicationContext and its related objects to see what could be done to enable dynamically-loaded JAR files within a parent Spring application context. Here is what I’ve discovered we can do, with only some small restrictions on developers writing the individual EventHandler implementations.

The first issue is, we need to locate a set of Spring application context XML file which should be on the classpath but not yet instantiated into any live Spring context.

Assuming we’re in a bean that’s ContextAware or otherwise has access to the Spring application context which is loading it, after the parent context has loaded and initialized (there are method hooks for this sort of thing) we can use the org.springframework.core.io.support.PathMatchingResourcePatternResolver class to search the classpath for a resource:

  PathMatchingResourcePatternResolver pmrl = new PathMatchingResourcePatternResolver(context.getClassLoader());
  Resource[] resources = pmrl.getResources(
    "classpath*:/net/crazymcphee/dynamiccontext/*/Crazy*DynamicContext.xml"
  );

Looking at the Spring 2.5.6 source code we found that the String passed to the getResources() method isn’t a proper regular expression, which is a pity. So you can’t do something like look for **/Crazy*DynamicContext.xml and expect to match a file Crazy*DynamicContext.xml in any package. Also we found that it had to prefixed with that classpath*: … yes, the asterix, literally … else it wouldn’t search the classpath, as opposed to the file path. So we’re restricted in the above example to a file called Crazy<something>DynamicContext.xml in a package exactly one deep from net.crazymcphee.dynamiccontext … e.g. net.crazymcphee.dynamiccontext.package.CrazyMcpheeDynamicPackage.xml matches but net.crazymcphee.dynamiccontext.package.sub.CrazySubDynamicPackage.xml and net.crazymcphee.dynamiccontext.CrazySuperDynamicPackage.xml do not. Therefore we will have a restriction on what package the dynamic context can be in and what it’s name will be. I don’t think that’s too onerous on our developers – we just have to pick a sensible standard.

The next part of the problem is that we have to load the ‘Resource’ thus found into a Spring context. This is pretty easy:

 for (Resource r : resources) {
   GenericApplicationContext createdContext = new GenericApplicationContext(context);
   XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(createdContext);
   int i = reader.loadBeanDefinitions(r);
 }

The int i will be set to the number of beans found in the createdContext. The createdContext will have the original context as its parent context, so it can gain access to any beans defined there (and also, although we are yet to test this (!), it should also be intercepted by the AOP-based transaction interceptors in the parent, and so forth).

The only other part of the puzzle may be to query the createdContext to see if it has any target beans within it, luckily for us an ApplicationContext has a method getBeansOfType(Class clazz) which will load all the beans of a particular type:

  for (Resource r : resources) {
    GenericApplicationContext createdContext = new GenericApplicationContext(context);
    XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(createdContext);
    int i = reader.loadBeanDefinitions(r);
    Map map = createdContext.getBeansOfType(EventHandler.class);
    for (Object o : map.keySet()) {
      EventHandler handler = (EventHandler) createdContext.getBean((String) o);
      // do some programmatic manipulation with the EventHandler that we found here
    }
  }

Using these three Spring features will enable us to be able to place a JAR file containing an interface implementation, and a Spring context XML file matching a particular pattern, into the classpath of our WAR, and on restart, we can dynamically pick up the newly inserted features into our application installation. I’ll report back when we get an actual production prototype together that can do this. Hopefully it will be OK to put the code in the blog too (if we make it generic enough).

If you have any further ideas or refinements to this idea, please leave them in the comments!

I’ve worked on a successful (JSR168) portal implementation, just last year. I truly don’t see what the concept of ‘portal’ brings to a web application beyond what could be simply programmed into a customised web application. We used Spring MVC Portal running under Websphere Portal and calling back-end services deployed on a BEA Weblogic server using Spring remoting (note: not WSRP which would have probably massively increased complexity). The reason this mix of platforms (Websphere and Weblogic) was used was political, not technical. I believe the whole use of portals in general tends to follow organisation’s political and not technical needs.

Despite all that, overall the custom portlets and the project as a whole was quite successful and the customer satisfied with the result. However I felt the most difficult aspects of the project were the parts of the deployment that were left to the portal container to provide. These are the things that are touted as the ‘advantage’ using a portal container over a simple custom-built web application. Content management features caused the team members delivering these enormous headaches (and late nights) and the same can be said of the authentication and authorisation mechanisms employed. I felt we could have easily delivered these components using known JEE development APIs with all the customisation required by the customer in at least an equal amount of time.

As a contrast, we used Tapestry 5 to develop (actually, completely rewrite from an earlier phase one version in dire need of improvement) an administration component as a straight web application deployed into the Weblogic server. This took a pair of us less than two weeks to write using a functional-test-driven approach and delivered a very nice web app.

The issue of portal containers and standards being a political rather than a technical concern is particularly pertinent to me at the moment because it looks likely in the near future I’ll be working on another portal implementation for another client. I can’t be more specific regarding this but this particular client had already bought the portal server from a vendor and then approached consultants in order to get an actual implementation completed. Of course, no requirements gathering or analysis was done to determine if the portal solution was indeed the right one – the vendor’s sales team effectively provided the assurances of product suitability. Because the money is already spent and reputations already staked on the portal platform there’s no possible way a better solution can be suggested by any technical expert at this stage.

In my view, that’s the “relevance” of portal servers in the Java world. Vendor sales teams love to sell them.

Update

Jakub Holý makes an excellent observation about validity of the concept of a portal server:

It’s a pity that portals and portlets aren’t easier to use and haven’t made it into the mainstream, the abilities of content aggregation, personalization, uniform security etc. are promising and as we can see in the rise of personal mashups like iGoogle, the fundamental ideas behind portals are still valid and extremely attractive. I hope that some mashup technology will soon provide a viable, light-weight alternative to portals.

That’s an important point: iGoogle is the most widely used example of a “portal” architecture. The modern trend towards the “mashup” (especially in social software) also shows the idea to aggregate different web applications under a common view, with security and other features is a valid one: it’s just the bloated, slow specification process, and predatory vendor sales departments that are stopping real innovation in this space in the Java area. Hopefully some light weight technology will soon emerge from among something like Spring, Tapestry, and GWT to produce a “portal” server that delivers actual value, and ease of development, deployment and usage, in a corporate context.