Damn email delays.
Hiram Chirino wrote:On May 18, 2005, at 9:55 AM, Jeremy Boynes wrote: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.
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.
Although there may be reasons wrapping is needed, this is not one of them. As this level the IoC is transparent.
An at other levels the IoC is not not transparent. The mere fact that references are proxied introduces a level of non transparency. Example: if a proxy reference is used as a key in map then the proxy will break the equals(Object o) implementation since the class of the object and the proxy to the object's class are not the same.
<snip/>
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.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.
OK, but that's a different requirement really :-)
I'm just saying the don't sound like managed objects to me. Do you think everything should be a managed object? It's such a pain to provide an object name for stuff that that is only going to be referenced by one object and that you don't even need exposed for runtime management.
- I was wrappering each component to define the gbean info for each component.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.
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.
Yep I was going down that route and I actually had a prototype working that defined the GBeanInfo via XML configuration. I was hoping that by doing that geronimo would tottaly transparent and I would not have a geronimo dependency the activemq components. But I started running into the roadblocks that caused me to notice that I had to wrapper my objects and I dropped the idea since I was going to have to depend on the geronimo jars anyways to implement the wrappers.
- 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.
That would be nice :)
- 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 didn't know we had a gbean in the default geronimo deployment that implemented DataSource. What's it's object name?
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'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?
I had a quick look and, assuming we can address the lifecycle issue, I didn't see anything obvious that we could not support.
Well it's been a long time since I did that gbean exercise for activemq I hope I'm not forgetting anything. One thing in the back of my mind is that way references were working was breaking our model but that may have been fixed since when I was attempting this stuff. I think references are now valid once they have been injected into the constructor.
-- Jeremy
