geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: Spring integration...
Date Wed, 09 Feb 2005 01:46:25 GMT
Dain Sundstrom wrote:

> On Feb 8, 2005, at 5:09 PM, Jules Gosnell wrote:
>
>> David Jencks wrote:
>>
>> Fine, so how would you take an existing MBean instance and having 
>> translated its interface into GBeanInfo/Data register it with the 
>> kernel so that any tool attached to the kernel will see it ?
>
>
> You don't.  Your code can always mount a JMX object directly into a 
> JMX MBeanServer (assuming you started your server with one), and it 
> will be available via JMX.  You get what a JMX MBeanServer can provide 
> you.  You can even call GBeans via the JMX MBeanServer.  If you want a 
> kernel services like dependency management, life-cycle and 
> persistence, they you need to write a GBean.  Normally this is pretty 
> simplel; you skim off the JMX stuff to the core managed object, and 
> write a GBean info based on the core functionality.  If you used a 
> standard MBean, then there is nothing to skim off.
>
OK, read POJO instead of MBean - advance to Go and start again...

>> That's all i want and i cannot have, without jumping through hoops, 
>> because GBeanInstance will not accept an existing object, but insists 
>> on creating a fresh instance from a provided class. This is the issue 
>> that my patch addressed and that I have been trying to explain. 
>> Everything else is digression and red herring.
>
>
> GBeans are not designed to make everyone happy.  For a general purpose 
> IOC container, I normally suggest people use spring.  GBeans are 
> designed to make the job of implanting Geronimo easy.  If they happen 
> to be useful for others, then that is nice, but the main purpose of 
> GBeans will always be to make Geronimo easy to write.

fine - I now have code that can build a dynamic proxy and insert my POJO 
into the kernel using that. One problem - I need cglib 2.0.2. We are 
currently configured to run on 2.0 which does not have InterfaceMaker.

Should I start backporting InterfaceMaker to 2.0, or can we move up to 
2.0.2 or some version that has this class in it ?

Cheers,

Jules

>
> -dain



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