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
