Discussion:
[deployment][jsr77] Dependency code in AbstractStateManageable.
(too old to reply)
Greg Wilkins
2003-08-20 07:25:49 UTC
Permalink
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
**************************/
Greg Wilkins
2003-08-20 09:53:50 UTC
Permalink
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
Alex Blewitt
2003-08-20 11:00:14 UTC
Permalink
Post by Greg Wilkins
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.
Dain Sundstrom
2003-08-20 17:47:29 UTC
Permalink
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
Post by Greg Wilkins
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).
WebContainer
WebConnector
WebApplication
WebAccessLog
WebSessionManager
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.
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.
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
Dain Sundstrom
2003-08-20 17:29:11 UTC
Permalink
Post by Greg Wilkins
Can somebody explain what's the story with the dependency
code that has been checked in????? Dain - is that you???
Yes that was me.
Post by Greg Wilkins
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.
+ 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.
Post by Greg Wilkins
+ 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.
Post by Greg Wilkins
+ 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.
Post by Greg Wilkins
+ <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.
Post by Greg Wilkins
+ 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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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
*************************/
Sean Hamblett
2003-08-20 19:44:27 UTC
Permalink
On Wed, 20 Aug 2003 12:29:11 -0500
On Wednesday, August 20, 2003, at 02:25 AM, Greg Wilkins
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
Greg Wilkins
2003-08-20 22:29:02 UTC
Permalink
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
Post by Sean Hamblett
On Wed, 20 Aug 2003 12:29:11 -0500
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
Sean Hamblett
2003-08-21 00:07:41 UTC
Permalink
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
Post by Greg Wilkins
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
Post by Sean Hamblett
On Wed, 20 Aug 2003 12:29:11 -0500
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
Aaron Mulder
2003-08-20 22:50:21 UTC
Permalink
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
Post by Dain Sundstrom
Post by Greg Wilkins
Can somebody explain what's the story with the dependency
code that has been checked in????? Dain - is that you???
Yes that was me.
Post by Greg Wilkins
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.
+ 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.
Post by Greg Wilkins
+ 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.
Post by Greg Wilkins
+ 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.
Post by Greg Wilkins
+ <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.
Post by Greg Wilkins
+ 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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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
2003-08-20 23:31:23 UTC
Permalink
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
Post by Dain Sundstrom
Post by Greg Wilkins
Can somebody explain what's the story with the dependency
code that has been checked in????? Dain - is that you???
Yes that was me.
Post by Greg Wilkins
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.
+ 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.
Post by Greg Wilkins
+ 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.
Post by Greg Wilkins
+ 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.
Post by Greg Wilkins
+ <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.
Post by Greg Wilkins
+ 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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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
**************************/
Dain Sundstrom
2003-08-21 02:42:03 UTC
Permalink
Post by Greg Wilkins
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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
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).
Post by Greg Wilkins
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.
Post by Greg Wilkins
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.
Post by Greg Wilkins
Finally, I think we need to clarify the difference between
StateManageable
and Component.
I agree...
Post by Greg Wilkins
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
Greg Wilkins
2003-08-21 05:15:10 UTC
Permalink
[ 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.
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
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
Dain Sundstrom
2003-08-21 05:40:57 UTC
Permalink
Post by Greg Wilkins
-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?
Post by Greg Wilkins
Post by Dain Sundstrom
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....
Post by Greg Wilkins
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).
Post by Greg Wilkins
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
Greg Wilkins
2003-08-21 06:28:38 UTC
Permalink
Post by Dain Sundstrom
Post by Greg Wilkins
-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
Post by Dain Sundstrom
Post by Greg Wilkins
Post by Dain Sundstrom
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....
Post by Greg Wilkins
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).
Post by Greg Wilkins
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
gianny DAMOUR
2003-08-21 06:08:00 UTC
Permalink
Hello,
Post by Dain Sundstrom
Create an AbstractManagedObject which implements ManagedObject and
StateManageable.
I assume that ManagedObject will be an interface defining the
J2EEManagedObject. That AbstractManagedObject will be an implementation of
ManagedObject, in other words J2EEManagedObject, and also an implementation
of StateManageable.

If my assumptions are right, then it means that the 77 models/components
should extend AbstractManagedObject. I said in a previous memo, that this is
an implementation via inheritance of the problem. Even if inheritance is
fine for the StateManageable requirements, I still believe that a
composition will be more handy:

A component, which mirrors a specific J2EEManagedObject as defined by the
specifications, creates the relevant J2EEManagedObject. This
J2EEManagedObject is added to the 77 model. This additional layer, focused
solely on the 77 requirements, can then be used to manage the J2EE
applications. Up to the component to push the relevant pieces of information
to its mirroring J2EEManagedObject. Up to the J2EEManagedObject to trigger
the StateManageable operations on its related component.

I must have a look to the "Deployment" sub-project, but I assume that it is
easy to trigger the creation of J2EEDeployedObject when a EAR is deployed.
If this EAR contains a EJB, then an EJBModule is added to the previously
created J2EEDeployedObject instance. If this EAR contains a Web-app, then a
WebModule is created and also added to this J2EEDeployedObject. When I say
"added", it could be via the standard POJO style. However if you prefer a
JMX approach, one could modelize the 77 model via roles and relation types
and let the relation service deals with it.

I have surely missed something, so anyone could explain me why we are not
going into this direction?

Cheers,
Gianny

_________________________________________________________________
ninemsn Extra Storage is now available. Get five times more storage - 10MB
in your Hotmail account. Click here http://join.msn.com/
gianny DAMOUR
2003-08-21 23:09:26 UTC
Permalink
Hello,

I wrote:
<lot of things>
[...]
Post by gianny DAMOUR
I have surely missed something, so anyone could explain me why we are not
going into this direction?
[...]
Disregard the whole message.

Sorry.

_________________________________________________________________
MSN Messenger 6 http://g.msn.fr/FR1001/866 : dialoguez en son et en image
avec vos amis.
Chris Opacki
2003-08-22 00:01:14 UTC
Permalink
Anyone come across these compile errors? What might I
be missing?

default:
java:prepare-filesystem:

java:compile:
[depend] Deleted 0 out of date files in 0 seconds
[echo] Compiling to
c:\project\ApacheJ2EE\incubator-geronimo\modules\core/ta
rget/classes
[javac] Compiling 155 source files to
C:\project\ApacheJ2EE\incubator-geroni
mo\modules\core\target\classes
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:89:
'class' or 'interface' expected
* @version $Revision: 1.7 $ $Date: 2003/08/18
22:03:38 $
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:89:
illegal character: \64
* @version $Revision: 1.7 $ $Date: 2003/08/18
22:03:38 $
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:91:
'class' or 'interface' expected
import
org.apache.geronimo.deployment.service.MBeanOperation;
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:92:
'class' or 'interface' expected
import org.apache.geronimo.jmx.JMXUtil;
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:100:
illegal start of expression
private final MBeanServer server;
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:101:
illegal start of expression
private final ObjectName parent;
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:104:
illegal start of expression
private final MBeanMetadata metadata;
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:105:
illegal start of expression
private ObjectName actualName;
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:106:
illegal start of expression
private boolean createCalled;
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:132:
illegal start of expression
public CreateMBeanInstance(Set plans, MBeanServer
server, ObjectName parent,
MBeanMetadata metadata, ObjectName loaderName) {
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:314:
illegal start of type
} catch (DeploymentException e) {
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:320:
<identifier> expected
}
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:322:
'class' or 'interface' expected

public void undo() {
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:363:
<identifier> expected
private static final Class[] stringArg = new
Class[]{String.class};

^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:365:
'class' or 'interface' expected

private Object getValue(ClassLoader cl, String
typeName, String value) throw
s DeploymentException {
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:392:
'class' or 'interface' expected

}
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\CreateMBeanInstance.java:393:
'class' or 'interface' expected

^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\StartMBeanInstance.java:98: illegal
start of expression
public void undo() {
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\StartMBeanInstance.java:157: ';'
expected
}
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\plan\StartMBeanInstance.java:159: '}'
expected
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\service\ServiceDeploymentPlanner.java:101:
unclosed comment
/**
^
C:\project\ApacheJ2EE\incubator-geronimo\modules\core\src\java\org\apache\geroni
mo\deployment\service\ServiceDeploymentPlanner.java:308:
'class' or 'interface'
expected
^
22 errors

BUILD FAILED
File......
file:/c:/project/ApacheJ2EE/incubator-geronimo/
Element... maven:reactor
Line...... 37
Column.... 7
Unable to obtain goal [default] -- file:/C:/Documents
and Settings/CO05680/.mave
n/plugins/maven-java-plugin-1.3/:55:48: <ant:javac>
Compile failed; see the comp
iler error output for details.
Total time: 3 minutes 19 seconds

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Chris Opacki
2003-08-22 00:57:17 UTC
Permalink
Nevermind...figured out the problem.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Loading...