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.
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.
-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
