On the Geronimo side, Spring should be able to access the ApplicationContext for any deployed .spr files and then merge this into deployed web applications using a ContextLoader (Spring thing). This will allow for service sharing in a Spring-style manner without the overhead of proxies. We could add proxies as a mechanism for surviving service reboot as well, but the option to go without proxies might be wise. The main barrier here is the whole classloading murk, but it should be that much of an issue.
Rob
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
