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