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 15:54:12 GMT
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...

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 ?



> Jules
>> Rob
>> Jules Gosnell wrote:
>>> Rob Harrop wrote:
>>>> Jules,
>>>> I think it is best to keep the metadata in geronimo-spring.xml, 
>>>> purely because spring.xml has no support for modifying the XML 
>>>> format. You want that to be a standard Spring config with no 
>>>> special features.
>>> I though you might say that :-)
>>> We will end up with an xdoclet template to generate a 
>>> geronimo-spring.xml with metadata about classes and methods that 
>>> need exposing and keep it in sync with the code.... - maybe this can 
>>> be done via source-level attributes...
>>> Does Spring not have any tag (or requirement for one - e.g. for JMX 
>>> exporting), which, in a Geronimo context, might be overloaded to 
>>> mean "export to Geronimo kernel" rather than just "export to JMX 
>>> Agent" ? i.e. just "export to relevant infrastructure".
>>>> From a Spring perspective, the two things we need are JMX-exposed 
>>>> POJOs, which we can already do, and a JNDI-bound ApplicationContext 
>>>> which will allow for transparent merging of shared services into an 
>>>> application.
>>> The more I'm learning about this stuff, the less straightforward it 
>>> is becoming :-(
>>> It doesn't seem enough to just expose POJOs to JMX, since Geronimo 
>>> doesn't necessarily use it - we have to expose ourselves to the 
>>> kernel as GBeans, which means that the Spring JMX support needs to 
>>> kick out something which can be transformed into/look like a GBean 
>>> description, or we need to build it from the ground up.
>>> Re JNDI - from what David is saying, it looks like being a 
>>> well-named GBean may be enough to get us published via JNDI. I will 
>>> investigate this more today.
>>> Happy hacking ;-)
>>> Jules
>>>> Rob
>>>> Jules Gosnell wrote:
>>>>> I've taken all of the points raised on board and just checked in 
>>>>> the second cut, which splits Spring support into runtime and 
>>>>> deploy time components.
>>>>> I'm still having trouble getting the Builder spotted by the 
>>>>> Deployer, but as long as I run the DebugConsole config aswell I am 
>>>>> OK - I'll look further into it when the dust dies down.
>>>>> If anyone wants to take another look at the code and comment (yeah 
>>>>> - I know it's ugly at the moment) that would be gratefully received.
>>>>> Rob, what are your thoughts on publishing POJOs to the Geronimo 
>>>>> kernel ? Do we just blindly export all of them, can you attach 
>>>>> metadata in the spring.xml or source, or do you think it should go 
>>>>> in the geronimo-spring.xml.
>>>>> Logically, I think it should go in the latter, however, 
>>>>> pragmatically, this will lead to a maintenance nightmare as 
>>>>> spring.xml moves on and geronimo-spring.xml fossilises, so I would 
>>>>> rather see a single descriptor... - I guess we could do both ?
>>>>> Anyone have any interesting thoughts ?
>>>>> Jules

"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