geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
Date Thu, 21 Aug 2003 02:42:03 GMT
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


Mime
View raw message