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