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