geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <>
Subject Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
Date Wed, 20 Aug 2003 23:31:23 GMT


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.

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.

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.

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

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 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


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.

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.

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.

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 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

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.

Finally, I think we need to clarify the difference between StateManageable
and Component.
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.


Dain Sundstrom wrote:
> On Wednesday, August 20, 2003, at 02:25 AM, Greg Wilkins wrote:
>> Can somebody explain what's the story with the dependency
>> code that has been checked in????? Dain - is that you???
> Yes that was me.
>> A lot of the deployment dependancy code appears to have been
>> added to the the AbstractStateManageable class and the
>> semantics of startRecursive have been changed significantly.
>> I don't think this is right on a number of fronts:
>>  + AbstractStateManageable should simple be an implementation of
>>    StateManageable and should run the JSR77 statemachine - nothing else.
>>    So at least the dependency code should have gone into 
>> AbstractComponent.
> The specification clearly states that start recursive will start the 
> component and then start recursive of the components that depend on that 
> component.
> My guess is you find it weird that the component does not need to have a 
> 'children' collection.  If we are going to allow generic services to 
> have dependencies, we need to be able to keep the dependencies out side 
> of the component, so I added a dependency service modeled after the JMX 
> relation service.
>>  + The definition of startRecursive in the spec is for children to
>>    be started.  I implemented this a the containment tree (Eg Geronimo
>>    contains WebContainer contains WebApplication contains Servlet).
>>    I don't think that the dependent components can be interpretted as
>>    child components.
> ...and you can still have explicit children.  Just extend doStart, 
> doStop, canStart and most important canStop, because you can not stop 
> until all of your children are stopped.  You will also have to listen 
> for state change events from your children (so you can move from 
> stopping to stopped) and you will have to listen to state change events 
> from your parent (so you can fail when your parent fails).  Or you can 
> just register the children as dependencies in the dependency service and 
> it all happens automatically.
>>  + I don't think that components should be responsible for dependancies
>>    anyway.  Dependancy checking should be done at a higher level and
>>    the caller of start() (ie the deployer) should be responsible for
>>    calling start() on the dependant services.    Sure components should
>>    define what their dependencies are  - but should not be actually
>>    enforcing them.
> And they are not... well the current implementation requires you to 
> extend AbstractStateManagable, but I am going to start on a ModelMBean 
> implementation that will wrap any service or POJO, and will add things 
> like automatic state management and configuration persistence.  The 
> directions to the deployment and dependency service will include a 
> section on how to make delegate object from AbstractStateManageable.
>>  + <grump>I saw nothing in the deployment postings that said it was 
>> going to
>>    blat over the work done by me and others getting AbstractComponent
>>    and AbstractContainer working for the containment tree abd to be JSR77
>>    compliant. In fact I can't see where this stuff has been discussed
>>    at all?</grump>
> I did not 'blat' (whatever that means) over your work.  Everything you 
> did is still there.  If you want to explicitly handle dependencies, you 
> can.
> As for discussions, we all agreed that we were doing 77, and this is 
> 77.  If the community doesn't like the implementation we can change it 
> or completely rewrite it.  Now we have a stake in the ground and can 
> talk about changing things.  Until there is some concrete code, people 
> tend to talk in circles because they all have a different starting point.
>>  + It has been done using the JMX style invoke semantics - while I 
>> think that
>>    may be OK for a higher level dependency service, I don't think it is
>>    appropriate for this low level of code.  Containers and Components 
>> have
>>    POJO references to each other and they should be able to call each 
>> other
>>    directly.  JMX style invocation should only come into play when we are
>>    talking about intercepted, multi-protocols, multi-JVM issues 
>> invocation -
>>    which I don't think is the case for AbstractStateManageable.
>>    It certainly should not have an ObjectName - as that is Component 
>> stuff.
>>    (and JSR77 tells us to make it a string anyway).
> I have no idea what you are talking about.  If a component wants to 
> maintain a list of POJOs as state managables it can.
> I for one don't think you want to do this, as the child POJOs tend not 
> to be services or have a separate live cycle from the parent.  A good 
> example of this is the interceptor chain. They have a very simple state 
> model, running or stopped, and even these are completely tied to the 
> container life cycle.  A better idea is to just keep a list around and 
> start and stop them in response to events on the container.  BTW, I'm 
> not talking about servlets as they do have a separate life cycle from 
> the containing web application.
> Anyway, there is nothing stopping you from managing POJOs like a state 
> manageable other then a bunch of code.  If they are JMX objects then we 
> need to treat them as such.
>> So can we:
>>  a) At least move this stuff out of AbstractStateManageable (as other 
>> things
>>     that are not components may well be StateManageable) and into 
>> Component (as
>>     a temporary home).
> No. There are things in the system that are not components, but just 
> simple services that will use AbstractStateManageable directly or will 
> want to create a delegate from it.
>>  b) Revert to containment semantics for startRecursive
> No you will break the dependency system in the deployment system, and 
> that is what 77 calls for.
>>  c) Have a bit more of a discussion about how & WHERE the dependency code
>>     is going to be implemented.
> Yes.  Definitely.  I will post an email later describing how to use the 
> deployment and dependency systems.
>> I can do a) without breaking anything.   But b) & c) are going to need
>> somebody else's assistance.
> Don't do it.
> -dain
> /*************************
>  * Dain Sundstrom
>  * Partner
>  * Core Developers Network
>  *************************/

  * Greg Wilkins
  * Partner
  * Core Developers Network

View raw message