Re: [deployment][jsr77][web] Dependency code in AbstractStateManageable.

[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.

[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.

[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.