On Friday, January 2, 2004, at 09:36 PM, Dain Sundstrom wrote:
So I have been thinking about this for a while now...
The big problem is the support for multiple targets under a single GeronimoMBean. If we didn't have multiple targets we could easily move from starting to running by calling the doStart method. If that method threw a WaitingException (or whatever we call it), we would leave it in the starting state, and if it threw anything else we would fail the component. This would also make implementing this code much easier.
The biggest and only user I know of for multiple targets is JCA. JCA uses this to expose the properties of a connection, which are not known ahead of time.
That is not what jca uses them for . Constructing GeronimoMBeanInfo dynamically to expose the actual attributes of the ManagedConnectionFactory or ResourceAdapter is easy and does not require more targets.
The problem that I don't know any other way to solve in Geronimo is that there are several lifecycle methods in which one adapter component is used as an argument to another. Since both the recipient and arguments are supplied by the resource adapter, I believe we have to use the actual classes rather than any enhanced proxies. Therefore I need some way of getting to the object wrapped in the geronimo mbean. Helper targets provide a convenient way to do this: one target can get all the other actual target objects, and call a method on the other mbean.
I don't want to have one big mbean that manages all the parts, because the parts have more or less independent lifecycles and there are some one to many relationships.
In JBoss I implemented things like this using a combination of taking advantage of the jboss jmx implementation to get the wrapped objects and the jboss mbean interceptors. So far I believe the multi-target approach is far superior.
I propose we ditch multiple targets for a DynamicGBean interface. If a GBean wants to define the interface at runtime, it simply implements this interface just like a DynamicMBean. I like the idea of a DynamicGBean being able to use the normal attribute and operation mapping for most methods and the dynamic interface for only the stuff.
Comments?
This is probably possible to do and rewrite the jca stuff to do.
However, I think a simpler and far more powerful solution is to simply require the default target to manage all of the lifecycle methods. This would avoid the need to write silly dynamic mbean dispatch methods and solve your worries about incomplete start/stops.
I'd also suggest separating the setMBeanContext method from the lifecycle methods. I noticed that most of the mbeans I converted recently needed one or the other but not both.
david
-dain
