Hiram Chirino Sr. Architect LogicBlaze, Inc. - a Simula Labs Enterprise [EMAIL PROTECTED] www.logicblaze.com On May 18, 2005, at 12:28 AM, David Jencks wrote:
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?
We just xslt to normal spring xml and pass that to spring.
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.
I tried providing GBeanInfo for the existing components. I ran into a few problems. The first is that they take complex objects for configuration. The second is that the gbean lifecycle did not really mesh well with the activemq lifecycle. The third is that we don't really want proxied references.
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
I would be quite happy with a single manageable component for our configuration since the whole broker is deployed as a unit. But I would also like to a managable components are runtime for stuff like: client connections, broker connections and dynamically created destinations.
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.
yes. I would not mind the many-little-gbean approach if I did not have to wrapper all the activemq components. I also would not bind the 1 big gbean solution if it did not have the serialization consequences.
Regards, Hiram
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.
