This looks very good.
Most of this will happen more or less automatically if you deploy each spring component as a gbean and give them jsr-77 like names.
We don't use mbeans any more.
We don't have a global jndi context: components' jndi component context is resolved entirely based on gbean object names. By using jsr-77 naming conventions systematically we can resolve most references based on only a small portion of the object name (the "name" key).
So, if you give the spring gbeans appropriate names they will be findable by the existing name resolution process (although it might need a little tweaking)
The object names in gbean references should give spring gbeans access to all other components in geronimo, j2ee and non-j2ee alike. This gives injection of components into other components. We generally prefer constructor dependency injection but the gbean infrastructure also supports setter injection.
What gets injected is a proxy giving geronimo some control over the lifecycle of the components.
Hope this helps, david jencks
On Jan 28, 2005, at 7:56 AM, 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
-- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it."
/********************************** * Jules Gosnell * Partner * Core Developers Network (Europe) * * www.coredevelopers.net * * Open Source Training & Support. **********************************/
