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... (Dain, David, Jeremy,... - Please read)
Date Wed, 02 Feb 2005 19:44:40 GMT
Dain Sundstrom wrote:

> On Feb 2, 2005, at 7:54 AM, Jules Gosnell wrote:
>> Jules Gosnell wrote:
>>> Rob Harrop wrote:
>>>> Jules,
>>>> The Spring config file does not change when new modules are added, 
>>>> it is generic enough to support most configuration options. For JMX 
>>>> metadata we currently use interfaces or source level metadata 
>>>> (Commons Attributes or Annotations). I am working on an XML-based 
>>>> JMX descriptor, but this is separate from the core config file. You 
>>>> can hook into the JMX registration process by implementing the 
>>>> RegistrationStrategy interface and you can then transform the MBean 
>>>> into a GBean. The MBeans we use are ModelMBeans so you can get all 
>>>> the metadata from that.
>>> Excellent :-)
>>> I am just putting in a placeholder POJOGBean that wraps each POJO, 
>>> but the API is simply that of GBean (i.e. has one accessor 
>>> getPeer()) at the moment - I have to look into how we can 
>>> dynamically declare an interface's metadata to the kernel...
>> I'm looking at how I can interface a POJO with the Geronimo kernel.
>> GBeanInstance has a concept of 'target' (see getTarget()) which 
>> GBeanAttributes and Operations seem to use to retrieve the object on 
>> which to act. So, this is good - I just need to make GBeanInstance 
>> wrap a ready made object (my POJO) instead of constructing another 
>> one...
> Please do not use this method.  It is simply there as a hack to allow 
> the kernel to get access to the internal instance of one gbean it 
> creates.  The GBeanInstance object itself is an internal detail of the 
> Kernel itself, and has been carefully written so user code should 
> never be able to obtain a reference to the instance object.  This 
> allows me to have complete freedom over the gbean implementation 
> behind the kernel interface.
>> However, the GBeanInstance ctor insists on creating a new object from 
>> scratch - no good if I want to just proxy one already existing in 
>> Spring.... (unless I add yet another layer of wrapping, which is not 
>> ideal).
>> So, I guess I am looking at altering or subclassing GBeanInstance to 
>> allow the passing in of an object to be wrapped and extending the 
>> Kernel with a method to loadGBean() around an already existing object.
>> Are the people who know about how the kernel works happy with this 
>> solution, or have I missed another way of achieving this ?
>> Are you happy for me to put this in, or would you like to do this 
>> yourselves ?
> The plan for integrating component frameworks such as spring is to 
> write a GBean component that holds the spring object delegates method 
> calls to it.  Yes this is another layer of indirection, but it can be 
> made very fast.  This way, spring can handle construction and your 
> GBean component simply wraps it.
So, given that the Spring component might be any POJO, this GBean 
(except that it doesn't have to be a GBean , only implement 
GBeanLifecycle, and it doesn't even seem to have to do that, as the 
kernel uses an instanceof test before calling lifecycle methods - only 
at a swift glance) needs to be either the POJO itself, or some form of 
engineered proxy, since we cannot be sure that the POJO implements an 
interface that we can 1.3-proxy. Regardless of which, we still need a 
way to push this instance into the kernel so it can be given to the proxy...

Is this how you would want to approach it ?


> -dain

"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