Jules,
You hit the nail on the head. At my current client, I just got done implementing Spring ApplicationContext objects into JNDI that are managed via JMX MBeans, so separate applications could share the POJOs between themselves. This proved to be huge when we are getting Portlets that need to leverage Spring based persistence layers between themselves.
One small hurdle to overcome is the ApplicationContext is not serializable, so wrapping this with a Serializable Adapter is a must. A pattern behind the scenes can make this seemless to the end user/developer, so they only work with the ApplicationContext.
This is good stuff.
Jeff
Jules Gosnell wrote:
So, Rob and I have been talking about exactly what we want out of the Spring integration...
I've thought a little and decided to share it with the whole list as well as Rob, so that anyone else with an interest can join in...
I think that the integration is really one of contained components, not the containers themselves. This means that things in the Spring world need to see things in the J2EE world in Spring terms and vice versa....
Lookup in the J2EE world, depending on granularity and indirection is done via JNDI or JMX, lookup is avoided in the Spring world and replaced with injection of POJOs into other POJOs.
This seems to be leading us towards :
- Spring must be able to resolve JNDI refs and inject the resulting POJO into Spring apps.
- Spring must be able to resolve JMX ObjectNames and inject a corresponding POJO (proxy) into Spring apps.
- Spring must export some/all managed POJOs into a JNDI registry
- Spring must register some/all managed POJOs as MBeans (via a proxy) with JMX Agent
Since we are in the Geronimo world we might reasonably expect some/all of these MBeans to be GBeans.
Geronimo supports inter-MBean dependendencies. Spring supports a POJO constuction-time dependency tree.
It makes sense to integrate these as well.
The results of this work should be transparent access to J2EE managed objects from Spring and vice versa. Spring components in one container could talk to those in another Spring container via a lookup through the J2EE layer, JNDI (if the relationship did not need to survive redeployment) or JMX (if it did), or could perhaps optimise this process by looking up each others BeanRegistries, which could be registered in JNDI/JMX anyway....
etc...
There are undoubtedly ClassLoading issues lurking here - more thought needed.
One last thing that would be very useful would be to somehow intercept Spring-managed calls to POJO-setters, and pass them through the POJO's GBean proxy. This should allow successful recording of configuration deltas, so that Spring-managed POJOs may have their state persisted like other GBeans. Can anyone more famailiar with the Geronimo kernel comment on this.... ?
How does that sound ?
Jules
