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 18:50:21 -0400 (EDT)
From: Aaron Mulder <ammulder@alumni.princeton.edu>
To: geronimo-dev@incubator.apache.org
Subject: Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
In-Reply-To: <D01C3205-D333-11D7-8482-000393DB559A@coredevelopers.net>
Message-ID: <Pine.LNX.4.44.0308201842440.29168-100000@www.princetongames.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

	Back in the day, someone (maybe me?) wrote a fancy dependency
manager for JBoss.  It was tossed out the window as "too complex" and the
code reverted to a scheme where the parts were loaded from the config file
in the order they were listed.  Under the KISS theory, I guess.

	So... Dain, can you explain the advantages of your dependency
manager over a simpler scheme?  The main advantage seems to be that you
can add/remove/start/stop/whatever new components at runtime, without
worrying about the order in which you do it.  Though it's still easy to
argue that a human can calculate the correct dependency order in 30
seconds while the code to do it dynamically on arbitrary objects is a lot
harder to digest, and now we need fancy semanticas for declaring at least
two different *kinds* of dependencies.  Is this really better than just
listing components in the right order to start (reverse order to stop)  
and mandating that you pay attention to that when you start or stop things
at runtime?

	Is it really better that you think you're going to be clever and
restart the JNDI service, and without your intention, the whole server
stops because every single component is indirectly dependent on it?  
Except maybe some happy little POJO that is now completely useless because
the rest of the server is down?

Aaron

On Wed, 20 Aug 2003, 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
>   *************************/
>