geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Harrop <r...@cakesolutions.net>
Subject Re: Geronimo/Spring integration - Moving forward...
Date Fri, 28 Jan 2005 17:04:12 GMT
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
>
>

Mime
View raw message