geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: Geronimo/Spring integration - Moving forward...
Date Fri, 28 Jan 2005 21:36:20 GMT
Dain Sundstrom wrote:

> Excellent work.
> One big issue here is Geronimo does not require JMX anymore.  JMX is 
> an option for the kernel but it is not a dependency or guaranteed to 
> even be available, so a JMX based solution will not work.  My guess is 
> we will need to write code similar to the existing spring JMX 
> integration code to produce GBeans.
OK - so I guess Rob needs to compare dynamically generated MBean and 
GBean metadata and translate JMX descrips built by Spring into gbean 
descrips - or start from scratch :-)

> On another note, I plan on (I even have some starter code) supporting 
> injecting GBean references into the J2EE enc so J2EE components can 
> obtain proxies to GBeans automatically. So if the Spring objects are 
> registered as GBeans then they would automatically be available to all 
> J2EE components.
Sounds good - I'll start looking at all this stuff soon,


> -dain
> -- 
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26
> On Jan 28, 2005, at 9:04 AM, Rob Harrop wrote:
>> I think it might be an idea to create a GBean for the Spring 
>> ApplicationContext but not for each bean. Spring will have the 
>> ability to register with JMX for bean management, plus some Spring 
>> beans have weird lifecycles which are better handled internally. 
>> Spring currently doesn't provide a management layer for the 
>> ApplicationContext which is where I see the GBean coming in.  Using 
>> this GBean a custom Geronimo ContextLoader deployed in a web 
>> application should be able to access shared services  - or at least 
>> this is my vision.
>> Rob
>> Jeremy Boynes wrote:
>>> Jules Gosnell wrote:
>>>> 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.
>>> Traditionally, Spring has had to interface with the J2EE platform 
>>> provided by the container provider it was running in. I think with 
>>> Geronimo you have the chance to integrate very closely with the 
>>> container services it provides rather than to the generic J2EE world.
>>> For example, our EJB container depends on a TransactionManager in a 
>>> very similar way to Spring. It doesn't get this service by doing a 
>>> JNDI or JMX lookup, it declares a dependency and has it injected by 
>>> the kernel. This seems very similar to Spring's internal model.
>>>> 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....
>>> Why have two BeanRegistries? I would have thought if Spring could 
>>> delegate component registration to the Geronimo kernel there would 
>>> be one unified view and dependency resolution mechanism which would 
>>> greatly simplify things.
>>> It is probably not obvious, but this is what our J2EE deployer does 
>>> - it converts the J2EE view of the world (java:comp/env JNDI refs 
>>> etc) into a set of dependencies managed by the kernel. This gets 
>>> pre-packaged into a Configuration containing just GBeans (plus code) 
>>> - the core runtime doesn't actually know much about J2EE at all.
>>>> etc...
>>>> There are undoubtedly ClassLoading issues lurking here - more 
>>>> thought needed.
>>> Hopefully that can be sorted out by the Configuration and Repository 
>>> subsystems.
>>>> 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.... ?
>>> If you have Spring creating the POJOs as GBeans then that will be 
>>> automatic - you just need Spring to generate the right GBeanInfo and 
>>> GBeanData.
>>> One word of caution though is that GBeans are optimized for 
>>> long-running objects, multi-threaded containers basically rather 
>>> than instances, so if Spring is continually rebuilding graphs of 
>>> instances this will not work very well.
>>> For example, in EJB land, we create a GBean for each EJB container 
>>> but do not create GBeans for individual EJB instances - it is the 
>>> EJB container rather than the kernel that managed the pool/cache of 
>>> those. We do this as the container is long lived and manageable but 
>>> individual instances are much more transient. On the other hand, in 
>>> Servlet land we do create a GBean for each Servlet as servlet 
>>> instances tend to live for the lifetime of the application.
>>> -- 
>>> Jeremy

"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)
 * Open Source Training & Support.

View raw message