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,
Jules
-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)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
