geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@gluecode.com>
Subject Re: Geronimo/Spring integration - Moving forward...
Date Fri, 28 Jan 2005 16:28:12 GMT
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.
> **********************************/
>


Mime
View raw message