geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Harrop <r...@cakesolutions.net>
Subject Re: Geronimo/Spring integration - Moving forward...
Date Wed, 02 Feb 2005 11:32:26 GMT
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.

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
>>>
>>>
>
>

Mime
View raw message