Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <4200F7A4.90103@coredevelopers.net>
References: <41F985BC.2060303@coredevelopers.net>
 <41FA0EE3.70402@cakesolutions.net> <41FA17C2.2080705@cakesolutions.net>
 <41FA27C6.2040005@coredevelopers.net>
 <F465B6CB-713B-11D9-A4A9-000D93361CAA@gluecode.com>
 <41FA60AF.9010909@coredevelopers.net> <41FA6E6A.3050006@apache.org>
 <41FA708C.3050007@cakesolutions.net>
 <488CDCAD-716F-11D9-9297-000D93C5B79C@gluecode.com>
 <41FAB054.5070603@coredevelopers.net> <41FAB467.5070201@cakesolutions.net>
 <420039B0.3080009@coredevelopers.net> <4200AEB2.2090905@cakesolutions.net>
 <4200B4A1.1040208@coredevelopers.net> <4200BA4A.1050001@cakesolutions.net>
 <4200BFFE.3030807@coredevelopers.net> <4200F7A4.90103@coredevelopers.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <DF2C5860-7534-11D9-9E3B-000D93361CAA@gluecode.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <djencks@gluecode.com>
Subject: Re: Geronimo/Spring integration - Moving forward... (Dain, David,
 Jeremy,... - Please read)
Date: Wed, 2 Feb 2005 08:09:52 -0800
To: dev@geronimo.apache.org


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?

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.
> **********************************/
>