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...
Date Wed, 02 Feb 2005 11:56:46 GMT
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...


> 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