You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Greg Wilkins <gr...@coredevelopers.net> on 2003/08/20 09:25:49 UTC
[deployment][jsr77] Dependency code in AbstractStateManageable.
Can somebody explain what's the story with the dependency
code that has been checked in????? Dain - is that you???
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 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.
+ 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.
+ <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>
+ 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).
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).
b) Revert to containment semantics for startRecursive
c) Have a bit more of a discussion about how & WHERE the dependency code
is going to be implemented.
I can do a) without breaking anything. But b) & c) are going to need
somebody elses assistance.
cheers
--
/**************************
* Greg Wilkins
* Partner
* Core Developers Network
**************************/
Re: [deployment][jsr77][web] Dependency code in AbstractStateManageable.
Posted by Dain Sundstrom <da...@coredevelopers.net>.
The dependency service supports two types of dependencies: start and
create. A start dependency means that another service must be in the
running state before you can transition to the running state, and
anything that has a start dependency on you must be stopped before you
can stop. A create dependency means that a service must be registered
with the specified name before you can start, and something you have a
create dependency on unregisters while you are running you move to the
failed state.
The DependencyService tracks all of this information for you all you
need to do is register the dependencies with the service (see the
interface it is straight forward). In addition the DependencyService
can run the dependency logic and tell you if you are allowed to move to
running, or move to stopping. I also added the synchronization code to
handle multithreaded stops, starts, and events (which does happen).
The DependencyService also has a shouldChangeState method where it can
advise an object to stop or fail. This is necessary, because as
objects unregister or fail, the services that depend on it must fail.
If you want to differentiate dependency from containment you can simply
do this (assuming it is state manageable):
public void addChild(StateManageable child) {
dependencyService.addStartDependency(getObjectName(),
child.getObjectName());
myChildren.add(child.getObjectName());
}
Now the startRecusive and stop methods will automatically, handle your
children. If you prefer to do it by hand, just implement canStop,
where you will check if all children are stopped, and the doStop method
to stop all of your children. You will also need to listen for events
from all children and move to stopping when all children eventually
stop. Be careful, because the synchronization is a major pain.
-dain
On Wednesday, August 20, 2003, at 04:53 AM, Greg Wilkins wrote:
>
> Just to follow up on my own email.... I'd like to explain how
> I see the deployment, container and component stuff working for
> the web stuff (this is in the wiki, but I'll say it here).
>
> I see the following web components:
>
> WebContainer
> WebConnector
> WebApplication
> WebAccessLog
> WebSessionManager
>
> Of these, WebContainer and WebConnector are Containers:
>
> Geronimo contains WebContainer(s)
>
> WebContainer contains WebConnector(s)
> WebContainer contains WebApplication(s)
> WebContainer contains WebAccessLog(s)
>
> WebApplication contains WebAccessLog(s)
> WebApplication contains Servlet(s)
>
> All of these are top level geronimo services that need to
> be configured, deployed, started, stopped, managed, viewed etc.
> They can all have different lifecycles and should all
> be geronimo Components. They can be put together in different
> combinations and will avoid the implementation dependancies of
> a monolythic webcontainer.
>
>
> I see the act of deploying a webapp as:
>
> 1) Create WebApplication
> 2) Call setXxx, setYyy on the WebApplication to configure it
> with the main one being setWebAppURI (to say where the WAR is).
> 3) Call WebContainer.addComponent(webApplication)
> 4) Call webApplication.startRecursive()
>
> I see this sort of this as 99% generic and was hoping that the
> deployment
> and dependancy mechanism would provide the infrastructure for this.
> I don't want to write more or less the same code to parse xml,
> configure
> components and add them to containers for all the above relationships.
>
> I see the dependancy mechanism as a tool to assist putting such
> containment trees together. ie be able to specify which webcontainer
> a webConnector is added to etc.
>
> I can see two types of dependancies:
>
> lifecycle : A depends on B means that B must be started before A
> containment : A depends on B means that B is added to A (and also
> implies
> lifecycle dependence).
>
> So that's the sort of thing we were looking for to be able to implement
> the webcontainer. That's what I had been working towards with
> AbstractComponent and AbsractContainer.
>
> cheers
Re: [deployment][jsr77][web] Dependency code in AbstractStateManageable.
Posted by Alex Blewitt <Al...@ioshq.com>.
On Wednesday, Aug 20, 2003, at 10:53 Europe/London, Greg Wilkins wrote:
> Just to follow up on my own email.... I'd like to explain how
> I see the deployment, container and component stuff working for
> the web stuff (this is in the wiki, but I'll say it here).
I think this is an excellent architecture, and one that could probably
be used with adjustments for the other containers in Geronimo (EJB, JCA
etc.)
Alex.
Re: [deployment][jsr77][web] Dependency code in AbstractStateManageable.
Posted by Greg Wilkins <gr...@mortbay.com>.
Just to follow up on my own email.... I'd like to explain how
I see the deployment, container and component stuff working for
the web stuff (this is in the wiki, but I'll say it here).
I see the following web components:
WebContainer
WebConnector
WebApplication
WebAccessLog
WebSessionManager
Of these, WebContainer and WebConnector are Containers:
Geronimo contains WebContainer(s)
WebContainer contains WebConnector(s)
WebContainer contains WebApplication(s)
WebContainer contains WebAccessLog(s)
WebApplication contains WebAccessLog(s)
WebApplication contains Servlet(s)
All of these are top level geronimo services that need to
be configured, deployed, started, stopped, managed, viewed etc.
They can all have different lifecycles and should all
be geronimo Components. They can be put together in different
combinations and will avoid the implementation dependancies of
a monolythic webcontainer.
I see the act of deploying a webapp as:
1) Create WebApplication
2) Call setXxx, setYyy on the WebApplication to configure it
with the main one being setWebAppURI (to say where the WAR is).
3) Call WebContainer.addComponent(webApplication)
4) Call webApplication.startRecursive()
I see this sort of this as 99% generic and was hoping that the deployment
and dependancy mechanism would provide the infrastructure for this.
I don't want to write more or less the same code to parse xml, configure
components and add them to containers for all the above relationships.
I see the dependancy mechanism as a tool to assist putting such
containment trees together. ie be able to specify which webcontainer
a webConnector is added to etc.
I can see two types of dependancies:
lifecycle : A depends on B means that B must be started before A
containment : A depends on B means that B is added to A (and also implies
lifecycle dependence).
So that's the sort of thing we were looking for to be able to implement
the webcontainer. That's what I had been working towards with
AbstractComponent and AbsractContainer.
cheers
Re: [deployment][jsr77][web] Dependency code in AbstractStateManageable.
Posted by Greg Wilkins <gr...@mortbay.com>.
Just to follow up on my own email.... I'd like to explain how
I see the deployment, container and component stuff working for
the web stuff (this is in the wiki, but I'll say it here).
I see the following web components:
WebContainer
WebConnector
WebApplication
WebAccessLog
WebSessionManager
Of these, WebContainer and WebConnector are Containers:
Geronimo contains WebContainer(s)
WebContainer contains WebConnector(s)
WebContainer contains WebApplication(s)
WebContainer contains WebAccessLog(s)
WebApplication contains WebAccessLog(s)
WebApplication contains Servlet(s)
All of these are top level geronimo services that need to
be configured, deployed, started, stopped, managed, viewed etc.
They can all have different lifecycles and should all
be geronimo Components. They can be put together in different
combinations and will avoid the implementation dependancies of
a monolythic webcontainer.
I see the act of deploying a webapp as:
1) Create WebApplication
2) Call setXxx, setYyy on the WebApplication to configure it
with the main one being setWebAppURI (to say where the WAR is).
3) Call WebContainer.addComponent(webApplication)
4) Call webApplication.startRecursive()
I see this sort of this as 99% generic and was hoping that the deployment
and dependancy mechanism would provide the infrastructure for this.
I don't want to write more or less the same code to parse xml, configure
components and add them to containers for all the above relationships.
I see the dependancy mechanism as a tool to assist putting such
containment trees together. ie be able to specify which webcontainer
a webConnector is added to etc.
I can see two types of dependancies:
lifecycle : A depends on B means that B must be started before A
containment : A depends on B means that B is added to A (and also implies
lifecycle dependence).
So that's the sort of thing we were looking for to be able to implement
the webcontainer. That's what I had been working towards with
AbstractComponent and AbsractContainer.
cheers
Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
Posted by Greg Wilkins <gr...@mortbay.com>.
Dain Sundstrom wrote:
> On Thursday, August 21, 2003, at 12:15 AM, Greg Wilkins wrote:
>
>> -1+1 Can you leave the code dealing with the state machine in
>> AbstractStateManageable. ie the setStateInstance check of the
>> lifecycle and the doStart and doStop abstraction to separate tasks
>> for this object from any coordinated start processing.
>
>
> Sure, but why do you need AbstractStateManageable specifically?
I actually have nothing specific at the moment in mind - but others
have asked for it - which is why it was factored out of component in
the first place.
The main reasons I want that layer is mainly for design clarity.
We are separating out an implementation of the JSR77 state machine
which is pretty generic - from our own managed object implementation
that is very geronimo/jmx/specific.
I think the code expresses the design a lot better when you can see
that ManagedObject and ManagedContainer are adding the intergration
with the dependency service to a state managed object.
We will be able to mess about with out components and container
code without accidentally changing the state model as enforced by
AbstractStateManageable.
cheers
>>> Drink a half dozen pints.
>>
>>
>> +1 (so long as it is in the order above).
>
>
> I already drank a bottle of wine so I'm done....
>
>> I also think you should make an ManagedContainer interface and
>> an AbstractManagedContainer class that would have all the
>> dependency service code in it. ie it would extend addComponent so
>> that a dependency is added to the dependency service when it is called.
>
>
> Well I did half of this. I added the rest of the types defined in 77 to
> the management package and added an AbstractStateMangeable which
> implements ManagedObject, StateManageable, and EventProvider (but not
> StatisticsProvider yet). I haven't touched the rest of the stuff in
> common yet, but I can when I wake up (unless you get to it first).
>
>> Actually... with that, I'd probably shut up on this issue as the
>> dependency mechanism integration into Component and Container would be
>> a lot more obvious - namely that the AbstractManagedContainer is really
>> just a conveniance class for configuring the dependency service.
>
>
> Okay... I glad we came to a good compromise.
>
> -dain
>
>
Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
Posted by Dain Sundstrom <da...@coredevelopers.net>.
On Thursday, August 21, 2003, at 12:15 AM, Greg Wilkins wrote:
> -1+1 Can you leave the code dealing with the state machine in
> AbstractStateManageable. ie the setStateInstance check of the
> lifecycle and the doStart and doStop abstraction to separate tasks
> for this object from any coordinated start processing.
Sure, but why do you need AbstractStateManageable specifically?
>> Drink a half dozen pints.
>
> +1 (so long as it is in the order above).
I already drank a bottle of wine so I'm done....
> I also think you should make an ManagedContainer interface and
> an AbstractManagedContainer class that would have all the
> dependency service code in it. ie it would extend addComponent so
> that a dependency is added to the dependency service when it is called.
Well I did half of this. I added the rest of the types defined in 77
to the management package and added an AbstractStateMangeable which
implements ManagedObject, StateManageable, and EventProvider (but not
StatisticsProvider yet). I haven't touched the rest of the stuff in
common yet, but I can when I wake up (unless you get to it first).
> Actually... with that, I'd probably shut up on this issue as the
> dependency mechanism integration into Component and Container would be
> a lot more obvious - namely that the AbstractManagedContainer is really
> just a conveniance class for configuring the dependency service.
Okay... I glad we came to a good compromise.
-dain
Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
Posted by Greg Wilkins <gr...@mortbay.com>.
Dain Sundstrom wrote:
> [ lots of stuff ]
I still don't agree with lots of what you said - but your concrete
proposals below I can mostly agree with - and we can debate the
details later.
> Here is what I plan on doing:
>
> Add a ManagedObject interface
+1
> Create an AbstractManagedObject which implements ManagedObject and
> StateManageable.
+1
> This class will contain a copy of the
> AbstractStateManageable code.
-1+1 Can you leave the code dealing with the state machine in
AbstractStateManageable. ie the setStateInstance check of the
lifecycle and the doStart and doStop abstraction to separate tasks
for this object from any coordinated start processing.
> Change existing code of mine that uses AbstractStateManageable to use
> AbstractManagedObject instead.
+1
> I propose that we do the following:
>
> Remove AbstractStateManageable, as I see no real users for it, but maybe
> you have a use.
-1 as above. AbstractStateManageable should exist and just have the
code to implement and enforce the StateManageable lifecycle.
> Drink a half dozen pints.
+1 (so long as it is in the order above).
I also think you should make an ManagedContainer interface and
an AbstractManagedContainer class that would have all the
dependency service code in it. ie it would extend addComponent so
that a dependency is added to the dependency service when it is called.
Actually... with that, I'd probably shut up on this issue as the
dependency mechanism integration into Component and Container would be
a lot more obvious - namely that the AbstractManagedContainer is really
just a conveniance class for configuring the dependency service.
cheers
Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
Posted by Dain Sundstrom <da...@coredevelopers.net>.
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
Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
Posted by Greg Wilkins <gr...@coredevelopers.net>.
Dain,
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
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 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);
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
level.
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.
cheers
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
**************************/
Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
Posted by Sean Hamblett <sh...@charter.net>.
Greg,
Thanks for clearing that up. I should have know it was my confusion. In
that case, if 77 is being applied to both Applications, and Server, should we
place a dividing line between the two? Implement 77 for the Applications,
and extend it for the servers, so we can take advantage of the life cycle,
performance, etc that 77 has to offer, and add in Geronimo specific stuff in
the extended version, for managing plugins, and services. By extending the
77 J2EEManagedObject Model and creating the GeronimoManagedObjectModel we
could use the existing spec for all, and add to it where needed to enhance
the management functionality of Geronimo.
Thanks,
Sean
On Wednesday 20 August 2003 06:29 pm, Greg Wilkins wrote:
> Sean,
>
> firstly let's not escalate this into a "flame war" status just yet. People
> can have different views of a problem and it's solution and express
> them rather strongly without it being a war.
>
> I believe that we should be using 77 to manage the application and the
> container. It makes little sense to me to have different lifecycles etc.
> But the point at hand is a little bit below 77 at the moment - it is how
> we organize our fundamental components... which just so happen to use 77
> APIs so that they can be 77 manageable once they are created.
>
> cheers
>
> Sean Hamblett wrote:
> > On Wed, 20 Aug 2003 12:29:11 -0500
> > Dain Sundstrom <da...@coredevelopers.net>
> >
> > wrote:
> >> On Wednesday, August 20, 2003, at 02:25 AM, Greg Wilkins wrote:
> >
> > I think we all agree that we are implementing 77, but I don't think we
> > all have the same definition of 77. I understand 77 to be about the
> > Application management, ie the manaegement of a deployed J2EE
> > Application, and all of its parts (encapsulated within the ear). What I
> > am hearing is 77 is about Application management, the Geronimo
> > Application and all if its parts. If I am wrong let me know, but to
> > help us work together I think we need to agree on what 77 means to us
> > before we get in a flame war over different definitions of the same spec.
> >
> > Regards,
> >
> > Sean
Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
Posted by Greg Wilkins <gr...@mortbay.com>.
Sean,
firstly let's not escalate this into a "flame war" status just yet. People
can have different views of a problem and it's solution and express
them rather strongly without it being a war.
I believe that we should be using 77 to manage the application and the
container. It makes little sense to me to have different lifecycles etc.
But the point at hand is a little bit below 77 at the moment - it is how
we organize our fundamental components... which just so happen to use 77
APIs so that they can be 77 manageable once they are created.
cheers
Sean Hamblett wrote:
> On Wed, 20 Aug 2003 12:29:11 -0500
> Dain Sundstrom <da...@coredevelopers.net>
> wrote:
>
>> On Wednesday, August 20, 2003, at 02:25 AM, Greg Wilkins wrote:
>
> I think we all agree that we are implementing 77, but I don't think we
> all have the same definition of 77. I understand 77 to be about the
> Application management, ie the manaegement of a deployed J2EE
> Application, and all of its parts (encapsulated within the ear). What I
> am hearing is 77 is about Application management, the Geronimo
> Application and all if its parts. If I am wrong let me know, but to
> help us work together I think we need to agree on what 77 means to us
> before we get in a flame war over different definitions of the same spec.
>
> Regards,
>
> Sean
>
Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
Posted by Greg Wilkins <gr...@mortbay.com>.
Sean,
firstly let's not escalate this into a "flame war" status just yet. People
can have different views of a problem and it's solution and express
them rather strongly without it being a war.
I believe that we should be using 77 to manage the application and the
container. It makes little sense to me to have different lifecycles etc.
But the point at hand is a little bit below 77 at the moment - it is how
we organize our fundamental components... which just so happen to use 77
APIs so that they can be 77 manageable once they are created.
cheers
Sean Hamblett wrote:
> On Wed, 20 Aug 2003 12:29:11 -0500
> Dain Sundstrom <da...@public.gmane.org>
> wrote:
>
>> On Wednesday, August 20, 2003, at 02:25 AM, Greg Wilkins wrote:
>
> I think we all agree that we are implementing 77, but I don't think we
> all have the same definition of 77. I understand 77 to be about the
> Application management, ie the manaegement of a deployed J2EE
> Application, and all of its parts (encapsulated within the ear). What I
> am hearing is 77 is about Application management, the Geronimo
> Application and all if its parts. If I am wrong let me know, but to
> help us work together I think we need to agree on what 77 means to us
> before we get in a flame war over different definitions of the same spec.
>
> Regards,
>
> Sean
>
Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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
> *************************/
>
Re: [deployment][jsr77] Dependency code in
AbstractStateManageable.
Posted by Sean Hamblett <sh...@charter.net>.
On Wed, 20 Aug 2003 12:29:11 -0500
Dain Sundstrom <da...@coredevelopers.net> wrote:
>On Wednesday, August 20, 2003, at 02:25 AM, Greg Wilkins
>wrote:
I think we all agree that we are implementing 77, but I
don't think we all have the same definition of 77. I
understand 77 to be about the Application management, ie
the manaegement of a deployed J2EE Application, and all of
its parts (encapsulated within the ear). What I am
hearing is 77 is about Application management, the
Geronimo Application and all if its parts. If I am wrong
let me know, but to help us work together I think we need
to agree on what 77 means to us before we get in a flame
war over different definitions of the same spec.
Regards,
Sean
Re: [deployment][jsr77] Dependency code in AbstractStateManageable.
Posted by Dain Sundstrom <da...@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
*************************/