Jules Gosnell wrote:
David Jencks 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...
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?
I'll check with Rob, perhaps we can take over the creation of Beans within Spring. I understand your reticence to wrap objects over whose lifecycle you have no control - perhaps you could think of it as delegating this control to another part of Geronimo, the SpringGBean, which in turn delegates it to Spring.
Bad news.
Has a good look around Spring and realised that this approach will hit a show-stopper. Spring allows the configuration of factory objects for contained beans. This means that bean construction can be done by user-space code. This code could be doing anything, so there is no way that Geronimo could replace it. We have no option therefore but to either say "We support a SUBSET of Spring" or extend the kernel to allow facading of existing beans as well as kernel-owned ones.
I would like to change the kernel - I don't think there is much value in Spring support if the first thing we do is to start eroding its feature set.
I am going to make some test alterations to the kernel and see if I can get it to work - I promise not to check anything in ;-).
I'll submit my changes to you, David, for review, if I am successful. Any further thoughts on the subject will be most welcome.
Jules
So, I can infer from this that there is no existing mechnism for plugging existing instances into the Geronimo kernel ?
Anyone else have any thoughts on this ?
Cheers,
Jules
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. **********************************/
-- "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. **********************************/
