geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Geronimo/Spring integration - Moving forward... (Dain, David, Jeremy,... - Please read)
Date Wed, 02 Feb 2005 17:52:11 GMT
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.


View raw message