Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Wed, 20 Aug 2003 12:29:11 -0500
Subject: Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Dain Sundstrom <dain@coredevelopers.net>
To: geronimo-dev@incubator.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3F43227D.6040102@coredevelopers.net>
Message-Id: <D01C3205-D333-11D7-8482-000393DB559A@coredevelopers.net>

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