geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: Geronimo/Spring integration - Moving forward... (Dain, David, Jeremy,... - Please read)
Date Wed, 02 Feb 2005 16:15:04 GMT
David Jencks 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...
>>
>> 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 ?
>
>
> This makes me extremely nervous.  We will have two dependency 
> management systems working on the same objects, and I think they will 
> surely conflict.
>
> What exactly does Spring do?  Can we get whatever it does in the way 
> of instantiation to create gbeans instead of POJOs?

I'll check with Rob, perhaps we can take over the creation of Beans 
within Spring. I understand your reticence to wrap objects over whose 
lifecycle you have no control - perhaps you could think of it as 
delegating this control to another part of Geronimo, the SpringGBean, 
which in turn delegates it to Spring.

So, I can infer from this that there is no existing mechnism for 
plugging existing instances into the Geronimo kernel ?

Anyone else have any thoughts on this ?

Cheers,


Jules

>
> thanks
> david jencks
>
>>
>> Are you happy for me to put this in, or would you like to do this 
>> yourselves ?
>>
>> Cheers,
>>
>>
>> Jules
>>
>>
>>
>>
>>>
>>> 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)
>> *
>> *    www.coredevelopers.net
>> *
>> * Open Source Training & Support.
>> **********************************/
>>


-- 
"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)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/


Mime
View raw message