On Wednesday, August 20, 2003, at 06:31 PM, Greg Wilkins wrote:
I think the fundamental difference between our views comes down to the containment tree. I think you believe that we don't need a real containment tree and have thus interpretted startRecursive to work over the dependancy tree.
No we need both, and startRecursive should start both. I think the difference is you believe that the trees should be mutually exclusive. I believe that containment is just a special kind of dependency and that the containment tree is a strict sub tree of the full dependency. I also think having all dependencies declared in a single place is a good thing for our container. It will be simple to debug, because you only have one dependency tree to deal with. As soon as you have more then one dependency system, debugging gets much more difficult.
I think that we do need a containment tree and believe that the initial design reflected this with the Component and Container classes and the design of the web container that I discussed.
Agree.
More over, if I want to have containment, I don't to have to implement addChild, doStart, doStop etc. etc. myself. I want to be able to extend AbstractContainer and have all the child management done for me in common code. This was how I had implemented AbstractContainer.
Agree, but that is what we have today. You call addChild and it declares the component in the dependency system. The contained component is after all dependent on the parent.
What I do like about your dependency service, is that it is as you say - to the side and a new service that can manage complex dependencies.
But I don't think that our very base component should have code that knows about this dependency service as includes it in the lifecycle.
I disagree. If we have dependencies then they must be honored in the live-cycle code.
I believe that if we want a start() call to work on the dependency tree, then we should ask the service that knows the dependency tree to manage that start. ie
dependencyService.startComponent(objectName);
I really don't like that. The dependency service's job is to track dependencies, not to start object. I also don't really like the canStart and canStop methods being in the dependency service as they really are not core to the service. It just was a nice place to sick them when I was writing the code. I think they should be moved to either AbstractStateManageable or a utility class.
It will then workout the dependancy tree, make a plan and implement
that plan - calling startRecursive on each of the components it identifies
in the depency treee. Each component is then only responsible for
starting its contained components - NOT calling back into the dependency
system to work out another dependency tree.
As each component starts a listening component may automatically start, stop or fail, so the dependency system must be checked. There is no point to work out the entire plan if you need to reverify the plan after each step.
If we want the dependency mechansim to be invoked automatically for
components, then we should do that with interceptors or notifications - not
by plumbing it into AbstactStateManageable.
That is not really possible with what we have. I am starting on a ModelMBean which does this in the wrapper layer.
So I see two ways forward:
1) Continue with Dependencies as a fundamental part of AbstractStateManageable.
In which case I think we should dump the whole Container and AbstractContainer
thing - they are not being used and they no longer mean anything. In
effect the dependency service will have become our uber-container and
all parent-child relationships will be established there.
All SMOs will be capable of being containers simply by creating a relationship
in the dependency service.
I don't like that. There is a special kind of dependency, a contained component, and it is useful to track them. I don't think we treat them specially during start and stop, but there may be special tasks for them.
2) Cleanly separate the concepts of dependencies and containment.
AbstractStateManageable, AbstractComponent & AbstractContainer are
reverted to being pure implementations of JSR77 over a containment tree.
The dependency code should be removed from AbstractStateManageable
and put into a startComponent method on that service.
I disagree with your connotation that the code is dirty. AbstractStateManageable is our implementation and we can implement it how ever we want. A user is always free to implement StateManageable directly (or use the ModelMBean when I get that done).
I clearly prefer 2) . I have a real need for simple containment and I just
don't think that a complex dependency service should be plumbed at the base
level.
It is not complex, but if you do want this, then what is you plan to handle generic dependencies like this?
<mbean code="org.apache.geronimo.deployment.dependency.Person" name="family:role=Parent">
<attribute name="Name">Parent</attribute>
</mbean>
<mbean code="org.apache.geronimo.deployment.dependency.Person" name="family:role=Child">
<attribute name="Name">Child</attribute>
<depends name="family:role=Parent"/>
</mbean>
BTW, you can do this for any MBean.
I could maybe live with 1) so long as we clarified and abstracted the whole
containment model - Ie we should either get rid of AbstractContainer - or
using it should automatically create relationships in the dependency service.
But I would still not like it.
We still need a container which maintains a list of contained objects.
Finally, I think we need to clarify the difference between StateManageable
and Component.
I agree...
I had implemented AbstractStateManageable as a POJO that could be used by
any object wanting to implement the JSR77 lifecycle. Component extended
this by adding an ObjectName (really should have been called ManagedObject).
It is at the Component level that I saw things like the dependency service
working - as they use ObjectNames to identify relationships.
StateManageables may not have an ObjectName and thus may not be able to be
represented in the dependency service - thus I think it is wrong for all
StateManageables to know about the dependency service.
Okay, I agree and disagree. StateManageable is an optional interface on a J2EEManagedObject, and I can't think of any place where you would have a StateManageable that is not J2EEManagedObject, but maybe you have a use I have not thought of. Here is what I plan on doing:
Add a ManagedObject interface
Create an AbstractManagedObject which implements ManagedObject and StateManageable. This class will contain a copy of the AbstractStateManageable code.
Change existing code of mine that uses AbstractStateManageable to use AbstractManagedObject instead.
I propose that we do the following:
Remove AbstractStateManageable, as I see no real users for it, but maybe you have a use.
Drink a half dozen pints.
-dain
