On May 17, 2005, at 3:19 PM, Hiram Chirino wrote:
Hi David,
Yes you are right. Our current activemq broker configuration is a bit simplistic. I wish it was as easy to support complex broker configuration in geronimo as it is in spring. With spring we can support a really rich broker configuration language see: http://activemq.codehaus.org/checkout/activemq/modules/core/src/conf/ org/activemq/activemq.dtd
Looks interesting. I don't know much about spring. Along with this dtd, what do you need to supply so spring will deploy and instance of this dtd the way it seems to imply?
The question is what's the simplest way to do something similar with geronimo? I tried using the GBean approach and it took down a route that seemed like I was going to have to create gbean wrapper classes for each activemq component. I was hoping for something more transparent since the ActiveMQ components are very IOCish I don't really see the need for extra gbean wrappers.
I'm not sure why you'd need wrappers rather than just GBeanInfos for each component. Could you explain? I would expect that it would be straightforward but probably more lengthy than what you do for spring to convert the dtd to a schema and write a builder that constructs gbean configurations from essentially the same configuration document as you are now using.
A question I have is, what is the size of unit that you want to be lifecycle-manageable? Each component in the broker config or the entire config as a unit? Do you want to be able to add more connectors, discovery agents, etc while the broker is running? If so I would think the many-little-gbean approach would be worth considering. If not I see why you were talking about making all the components serializable as a gbean solution; it would be pretty easy to write an xml-attribute builder to convert a config document into a configured broker, but at deploy time: the only obvious way to save it is indeed by serialization.
Hopefully the mailing list delay will go well under the current 6 hours so we can continue the discussion in more real time :-)
thanks david jencks
Regards, Hiram
On May 17, 2005, at 2:39 PM, David Jencks wrote:
Slow down a minute.
I just looked at the activemq gbeans used in geronimo currently and they appear to use for attributes only types from java.xxx. As I already indicated in a previous post, the possible problems come from changing classes used as attributes and changing the GBeanInfo classes themselves. An incompatible change in GBeanInfo classes is very likely to require redeployment of everything and redesign of the descriptors. Since activemq is only using standard java types as gbean attributes, activemq is free to change all their classes as they see fit and make none of them serializable as long as the types and names of the gbean attributes remain the same.
As far as the form of metadata needed for an IOC container, I currently prefer GBeanInfo to the alternatives I am aware of. I think it's important to specify exactly what interface is presented to the container, which IIUC spring does not require, and after working a lot with the jboss xmlbean implementation and writing the xdoclet xmlbeans plugin, I think that xml is perhaps the worst choice possible, and javadoc tags not much better.
thanks david jencks
On May 16, 2005, at 4:13 PM, Hiram Chirino wrote:
Hi,
From the ActiveMQ viewpoint, we would rather:
PROJECT POLL:
[ ] We will do our best to ensure the implementations of our APIs are serialization compatible to future versions of our code.
[X] We do our best to ensure our public APIs, but use of our implementations in such a way is not supported by us.
ActiveMQ standalone does not currently have these serialization issues so it's unfortunate that for us to play nice with Geronimo we would have to add on a Serialization requirement on our GBeans. It's actually quite unfortunate that ActiveMQ even needs to implement GBeans. It just proves that the geronimo IOC container is not transparent. And adding the Serialization requirements makes that even worse.
