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 17:26:29 GMT
Jules Gosnell wrote:

> 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.
>
Bad news.

Has a good look around Spring and realised that this approach will hit a 
show-stopper. Spring allows the configuration of factory objects for 
contained beans. This means that bean construction can be done by 
user-space code. This code could be doing anything, so there is no way 
that Geronimo could replace it. We have no option therefore but to 
either say "We support a SUBSET of Spring" or extend the kernel to allow 
facading of existing beans as well as kernel-owned ones.

I would like to change the kernel - I don't think there is much value in 
Spring support if the first thing we do is to start eroding its feature set.

I am going to make some test alterations to the kernel and see if I can 
get it to work - I promise not to check anything in ;-).

I'll submit my changes to you, David, for review, if I am successful. 
Any further thoughts on the subject will be most welcome.


Jules

> 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