Damn email delays.
Hiram Chirino wrote:
On May 18, 2005, at 9:55 AM, Jeremy Boynes wrote:
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.
Right. The problem with this approach is that I have to wrapper all the activemq components. In other words the IOC geronimo provides is not very transparent.
Although there may be reasons wrapping is needed, this is not one of them. As this level the IoC is transparent.
<snip/>
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.
Well, to me they are not really managed objects in the sense that they should not be changed at runtime. Most of these objects are just configuration options and I want them hidden from a users runtime management view.
OK, but that's a different requirement really :-)
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 was wrappering each component to define the gbean info for each component.
That's not necessary. You had talked at one point about generating GBeanInfo by introspecting the class to avoid needing to do this and I'll admit I thought that was what you were doing.
The GBeanInfo can come from anywhere and does not need to come from the implementation class. This is by design so that implementation classes can be completely Geronimo-free.
- I also adapting the life-cycle that geronimo provides so that it compatible with the life-cycle that activemq uses.
Ah - now that may require a wrapper. There is a limitation in GBeanInstance in that it requires the component to implement GBeanLifecycle (which is obviously not transparent (and obviously not related to Serialization :-) )). We should remove this limitation and support invocation of any implementation's lifecycle methods.
- I have components that need stuff like a DataSource injected into them via setter injection.
That should work just by using a reference to a GBean the exposes the DataSource interface.
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?
Well that's what I've had to do with the activemq integration so far. It's been painful. If there is an easier way I would love to know about it. If you want to see the current ActiveMQ integration, please look at http://svn.activemq.org/trunk/activemq/modules/gbean it not big a project since I only wrapped a few of the activemq components. It would be ideal if this could be reduced to no wrappers and maybe a simple builder that converts the activemq xml to some geronimo friendly format.
I had a quick look and, assuming we can address the lifecycle issue, I didn't see anything obvious that we could not support.
-- Jeremy
