If this is true, it seems plausible that you could provide an activemq-to-gbean.xsl that converted the instance document into a GBean service configuration file containing multiple GBean definitions linked together with GBean references and configured with attribute values. Given you have a DTD I would assume the values would be simple types and hence would not run into serialization problems.
That would be outstanding but the problem is that we are wiring runtime components not really designed to be serialized.
I must be missing something as I still don't see why serialization is an issue. The attribute values would be coming from XML and so would be simple types from the VM.
This means that we have to create gbean wrappers for all to components being wired. And doing that introduces the need to use proxied references which we really don't need.
Hmm - as I read this, you sound like you are trying to avoid any GBean references, which would make the entire broker config a single attribute and I agree that would impose the serialization requirement. I don't think that is the right way to go.
We also support letting users override the default implementation class for a component which could be hard to do with a hard coded gbeaninfo.
That should not be a problem - the GBeanInfo can be obtained independently from the implementation class and so could be created during the configuration build process by the XSLT or by the builder. I thought you were doing this already for the base components.
And there are many components that can take complex objects like WireFormat, DeadLetterPolicy, RedeliveryPolicy, etc. as configuration attributes which would run into the serialization problems if they were changed in future versions.
If they were attributes. But these sound like managed objects and the easiest way to do that is to create GBean instances for them and wire them together with GBean references.
You will only run into serialization issues if you start making incompatible changes to the attribute set for these objects as the loader is going to check that the attribute values contained in the state are valid for the instance they are being loaded into. This is not an issue with Java Serialization but a result of us checking for incompatible changes and would also be an issue with any form of XML persistence.
Also remember that this will be handled by the configuration manager ensuring that the right version of the ActiveMQ codebase is loaded for the broker configuration being run. I.e. if you give us a downrev configuration we will run it using a downrev broker.
You could also implement this as a Geronimo ConfigurationBuilder that took an activemq instance document and converted it directly to a Configuration which could then be directly installed into any server.
Sure that would be the way to do transformation from activemq xml to gbean configuration. But I still have the problem having to wrapper up a ton of the components.
I still don't get that unless you are trying to avoid using references.
I'm sure you tried that and there must be some problem I can't see on the surface - could you give us a bit more information on where it wasn't working?
I'm just giving grief cause Geronimo is so close to being able to be a transparent IOC framework. When I started doing the activemq implementation I noticed that it's not transparent at all. At least for the ActiveMQ case it almost seems like the IOC system is only really useful for wiring together a gbean model of the configuration of the system. Then those gbeans have to manually wire the ActiveMQ runtime components once they are started.
That's not the intention. It could be the result if you don't use any references, but that's not going to give you an good management structure for your objects either (which I assume is one of your intentions). I'd like to see a more concrete example - can we get on IRC later to work through it?
-- Jeremy
