Dain Sundstrom 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...
>
>
> Please do not use this method. It is simply there as a hack to allow
> the kernel to get access to the internal instance of one gbean it
> creates. The GBeanInstance object itself is an internal detail of the
> Kernel itself, and has been carefully written so user code should
> never be able to obtain a reference to the instance object. This
> allows me to have complete freedom over the gbean implementation
> behind the kernel interface.
>
>> 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 ?
>>
>> Are you happy for me to put this in, or would you like to do this
>> yourselves ?
>
>
> The plan for integrating component frameworks such as spring is to
> write a GBean component that holds the spring object delegates method
> calls to it. Yes this is another layer of indirection, but it can be
> made very fast. This way, spring can handle construction and your
> GBean component simply wraps it.
>
So, given that the Spring component might be any POJO, this GBean
(except that it doesn't have to be a GBean , only implement
GBeanLifecycle, and it doesn't even seem to have to do that, as the
kernel uses an instanceof test before calling lifecycle methods - only
at a swift glance) needs to be either the POJO itself, or some form of
engineered proxy, since we cannot be sure that the POJO implements an
interface that we can 1.3-proxy. Regardless of which, we still need a
way to push this instance into the kernel so it can be given to the proxy...
Is this how you would want to approach it ?
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.
**********************************/
|