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.
-dain
