[webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Jan Bartel <ja...@mortbay.com>]

 > It would be nice to get some help on
 > the web DD writer and DConfigBeans since it looks like we might actually
 > be able to deploy web apps in Jetty (is that right?).
The "proper" (as opposed to the temporary Jetty integration) webapp 
deployment mechanism is available now in it's early stage. An 
integration with this mechanism for the Jetty web container is also 
available.

To try it:

1. stop geronimo
2. remove the target/geronimo-DEV/deploy/jetty/jetty-service.xml file 
and replace it with the modules/web/src/dev-jetty-service.xml file
3. start geronimo

You should now be able to deploy packed wars and exploded wars via the 
normal geronimo deployment mechanism (ie dropping them in the 
target/geronimo-DEV/deploy directory). At the moment, wars containing 
uncompiled JSPs won't work, as an enhancement to Jetty is needed to 
extract a suitable JSP compile classpath from the geronimo classloader 
hierarchy before Jasper will be able to compile on-the-fly. Greg has 
this patch nearly ready. One caveat - I haven't had a chance to do much 
testing on this yet beyond dropping the geronimo-web-console.war into 
the deploy directory, so expect some surprises. Also be aware that there 
is no JNDI ENC support from the web deployer yet as there isn't (AFAIK) 
any datasources, ejbs etc yet within geronimo to put into such an ENC.

One valuable feature of the geronimo web deployment mechanism is that 
web layer objects such as listeners (aka connectors) and access logs are 
first class Geronimo services. This means that the configuration for 
them can be expressed in standard Geronimo mbean config syntax, rather 
than needing extra web-container specific config files. Here is the 
dev-jetty-service.xml file which contains all you need to get the Jetty 
container deployed and serving webapps on port 8088:


<components>
   <!-- ============================================================ -->
   <!-- Set up the Jetty-specific jars                               -->
   <!-- ============================================================ -->
   <class-space name="geronimo.system:role=ClassSpace,name=Jetty">
     <codebase url="file:lib/">
       <archive name="*"/>
     </codebase>
     <codebase url="file:../../lib/">
       <archive name="geronimo-core-DEV.jar"/>
       <archive name="geronimo-common-DEV.jar"/>
     </codebase>
   </class-space>

   <!-- ============================================================ -->
   <!-- Set up a Jetty container                                     -->
   <!-- ============================================================ -->
   <mbean code="org.apache.geronimo.web.jetty.JettyWebContainer"
          name="jetty:role=WebContainer">
    <attribute type="java.net.URI"
               name="DefaultWebXmlURI">file:web-defaults.xml</attribute>
   </mbean>

   <!-- ============================================================ -->
   <!-- Set up a connector to listen for http requests               -->
   <!-- ============================================================ -->
   <mbean code="org.apache.geronimo.web.jetty.JettyWebConnector"
          name="jetty:role=WebConnector, port=8088">
     <attribute name="Port">8088</attribute>
     <depends name="jetty:role=WebContainer"/>
   </mbean>
</components>


On my list for the very near future is:
+ support for undeploy
+ support for webdefaults
+ support for JSR88 required data for webapps
+ JNDI ENC
+ parsing of web.xml and geronimo-web.xml deployment descriptors
+ support for a geronimo web access log service
+ testing, testing, testing

The longer term:
+ more testing :-)
+ support for web apps deployed inside an ear
+ support for redeploy
+ support for registering context names with a listener which
   must be deployed on the container before the listener will
   accept connections
+ support for simultaneous deployment of different web containers (eg
   Jetty and Tomcat in parallel)


I will try to update all this on the Geronimo wiki in the next few days. 
Just thought as the subject came up, I'd give everyone an update on what 
is happening in web-app deployment land.

cheers
Jan

Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Jan Bartel <ja...@mortbay.com>]

> On my list for the very near future is:
> + support for undeploy
> + support for webdefaults
> + support for JSR88 required data for webapps
                    ^^
Ooops, I meant JSR077. But come to think of it, there may well be 
something to be done for JSR88 as well.


Jan

Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Greg Wilkins <gr...@mortbay.com>]

Jan Bartel wrote:

> You should now be able to deploy packed wars and exploded wars via the 
> normal geronimo deployment mechanism (ie dropping them in the 
> target/geronimo-DEV/deploy directory). At the moment, wars containing 
> uncompiled JSPs won't work, as an enhancement to Jetty is needed to 
> extract a suitable JSP compile classpath from the geronimo classloader 
> hierarchy before Jasper will be able to compile on-the-fly. Greg has 
> this patch nearly ready. 

Greg now has this patch ready and Jan has tested it and asked James to
update the Jetty-SNAPSHOT on imbiblio.

So when this is updated, we will need to switch from using the Jetty-4 jar
to using the Jetty-SNAPSHOT.  This will make JSPs work.

The other thing of note, is that I have finally ditched the Jetty logging
mechanism (which to be fair was written in 1996).  Jetty now uses commons
logging, so if you suddenly see a lot more gumpf coming out of your
TRACE and DEBUG - that is as expected and that gumpf was going on anway :-)

cheers

RE: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Aaron Mulder <am...@alumni.princeton.edu>]

	I agree with the ideas below.  One note: I'd like the default, if
no jndi-root is specified, to be that each application goes in its own
JNDI root (rather than defaulting to everything being shared in one).  
I'd also like to back this up with ClassLoader separation, so that if two
apps end up in different "spaces" then they can't poke each other at all,
except through the usual external interfaces.

	I think this separation would enable us to do some cool things, 
like mapping each application to a different security or transaction 
service, even while running in the same VM (in addition to the ability to 
set up different deploy dirs and different VMs to achieve the same thing).

	Finally, I'm expecting that a single EAR cannot span multiple 
vhosts.  You know, you can't wrap 1 JAR/WAR pair in 1 vhost block and 
another JAR/WAR pair in a different vhost block.  It looks like that's 
true from the snippet below, but I just want to make sure.

Aaron

On Mon, 6 Oct 2003, Jeremy Boynes wrote:
> You know, thinking about it there is nothing in the standard DD
> information about binding anything to the outside world. For a WAR file,
> there is nothing that defines the context or vhost, for an EJB file
> there is nothing that defines the EJBs JNDI name or vhost. An EAR file
> defines the context for a  web app, but says nothing for EJBs or vhosts.
> 
> This got me thinking we can have a common mechanism for specifying a
> root context for binding things too, with lower level overrides.
> 
> For example, in the geronimo-application.xml file we could have
> something like
> <application>
>    <ger:vhost>mydomain.com</ger:vhost>
>    <ger:jndi-root>ldap://dirserver/myapp</ger:jndi-root>
>    <module>
>       <web>
>         <web-uri>app1.war<web-uri>
>         <context-root>/app1</context-root>
>       </web>
>    </module>
>    <module>
>       <ejb>ejb1.jar</ejb>
>    </module>
> </application>
> 
> This would result in app1 being bound to all listeners for the host
> mydomain.com and the JNDI names for EJBs in ejb1.jar being bound to
> myapp context of the LDAP server on dirserver. Or at, least that's the
> general idea, a lot more detail is needed.
> 
> This sounds like information that would be passed in a DeploymentContext
> instance associated with the unit being deployed. Then the EARDeployer
> would read its geronimo DD and populate a WARDeploymentContext which
> would be passed to the WARDeployer; the WARDeployer works out the actual
> connector to use based on the information passed in from outside plus
> what it finds in its DD. The DeploymentContext is the bridge and there
> is no need for the EAR and WAR deployers to understand each other's DD
> POJOs.
> 
> --
> Jeremy
> 

RE: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Jeremy Boynes <je...@coredevelopers.net>]

> From: Jules Gosnell [mailto:jules@coredevelopers.net] 
> Sent: Monday, October 06, 2003 8:54 AM
> 
> One of the things that we omitted, then had to hack in, in a certain 
> other app server was virtual host support. Virtual hosts are 
> not (AFAIK) 
> yet supported by the std dd. Of course, they can be supported in a 
> proprietary dd (section), however, an number of people wanted e.g. 1 
> deploy dir per virtual host. I guess we need some sort of retrievable 
> deployment content object that holds e.g. parsed dds, who did the 
> deploying and other stuff, that the webcontainer may 
> OPTIONALLY dip into 
> in order to enrich it's understanding of what is going on. However 
> deployment should be able to go ahead without access to this context?
> 

You know, thinking about it there is nothing in the standard DD
information about binding anything to the outside world. For a WAR file,
there is nothing that defines the context or vhost, for an EJB file
there is nothing that defines the EJBs JNDI name or vhost. An EAR file
defines the context for a  web app, but says nothing for EJBs or vhosts.

This got me thinking we can have a common mechanism for specifying a
root context for binding things too, with lower level overrides.

For example, in the geronimo-application.xml file we could have
something like
<application>
   <ger:vhost>mydomain.com</ger:vhost>
   <ger:jndi-root>ldap://dirserver/myapp</ger:jndi-root>
   <module>
      <web>
        <web-uri>app1.war<web-uri>
        <context-root>/app1</context-root>
      </web>
   </module>
   <module>
      <ejb>ejb1.jar</ejb>
   </module>
</application>

This would result in app1 being bound to all listeners for the host
mydomain.com and the JNDI names for EJBs in ejb1.jar being bound to
myapp context of the LDAP server on dirserver. Or at, least that's the
general idea, a lot more detail is needed.

This sounds like information that would be passed in a DeploymentContext
instance associated with the unit being deployed. Then the EARDeployer
would read its geronimo DD and populate a WARDeploymentContext which
would be passed to the WARDeployer; the WARDeployer works out the actual
connector to use based on the information passed in from outside plus
what it finds in its DD. The DeploymentContext is the bridge and there
is no need for the EAR and WAR deployers to understand each other's DD
POJOs.

--
Jeremy

Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Jules Gosnell <ju...@coredevelopers.net>]

One of the things that we omitted, then had to hack in, in a certain 
other app server was virtual host support. Virtual hosts are not (AFAIK) 
yet supported by the std dd. Of course, they can be supported in a 
proprietary dd (section), however, an number of people wanted e.g. 1 
deploy dir per virtual host. I guess we need some sort of retrievable 
deployment content object that holds e.g. parsed dds, who did the 
deploying and other stuff, that the webcontainer may OPTIONALLY dip into 
in order to enrich it's understanding of what is going on. However 
deployment should be able to go ahead without access to this context?

If I am talking rubbish - it's because I haven't really been following 
this thread.... :-)


Jules




Greg Wilkins wrote:

>
>
> Aaron Mulder wrote:
>
>> Jan (and Greg),
>>     This looks cool.
>
>
> It's all Jan at the moment - I'm stuck into Jetty5 and making it a bit 
> more
> flexible to suit.  But happy to take credit for any of the cool bits :-)
> (NB. but I will soon to the clean up of Component and ManagedObject stuff
> that I spoke about some time ago).
>
>>     That said, I'd like to work on centralizing some of the deployment
>> logic.  All the work of dealing with deployment plans and tasks is going
>> to be fairly common across application module types, and we'll need to
>> bring a lot of it together when we deploy an EAR anyway (arranging
>> ClassLoaders and identifying context roots and so on).  Also, the JSR-88
>> model lets you distribute an application to one or more servers without
>> starting it, and the MBeans need to created at distribute time so 
>> they can
>> be invoked to start it.
>
>
> I think centralizing logic is a good thing to do, but I am very cautious
> about moving webapp specific knowledge out of the webcontainer itself.
>
> The common deployment planning should all be about abstract geronomo
> services and not about specific types of services.  Remember that
> the webcontainer, the webapp, the webconnector, the request log, etc
> are all first class geronimo services and we don't want to have to
> move detailed planning for all of these into a centralized spot.
>
>>     So I'd like to build most of that into the application deployer
>> service, and then have the application deployer call out to the
>> WebContainer, EJBContainer, etc. at a later stage, more like:
>>
>> start(String contextRoot, ClassLoader parent, File warDir, (DD POJO));
>
>
> This is exactly the sort of API that I would like to avoid.  The 
> deployment
> mechanism should only be calling standard JSR77 style start/stop methods
> and nothing specific to a webapplication.    I think all these parameters
> have better ways of being pased:
>
>  contextRoot - should be obtained from the DDs
>  parent - should be the Thread context loader for any call to the 
> service.
>  warDir - is a configuration parameter passed during construction of the
>           service.
>  DD POJO - The API should not reflect our POJO DD's.  A service should 
> be free
>            to read the DDs from disk if it want's to.  Of course we 
> want it
>            to use the preparsed POJO DD's for efficiency and dynamic 
> deployments,
>            but I think that should be an option for a well written 
> service.
>            Thus the service should use a DD API to ask for it's POJO 
> DD rather
>            have it pushed at it.
>
>> stop(...)
>> restart(...)
>>
>>     Does that sound reasonable to you?  Can you help me define what 
>> the WebContainer interface should look like for that?  For example:
>
>
> The webcontainer interface should look like a standard JSR77 lifecycle.
> Any bells and whistles we add should be common to all g-services and 
> nothing
> should be specific for webapplications.
>
>>  - Should we always unpack a WAR into a temporary dir before handing it
>> over, or are you just as happy to get a packed WAR file?
>
>
> I think unpacking should be the default option.  It can be handled by
> the common deployer - but not in terms of war's specifically.  I'd prefer
> to see it have a configurable none/shallow/deep unpacking mechanism that
> can be applied to arbitrary service bundles.
>
> So I think we should look to moving common code out of the webcontainer
> deployer, but let's try to keep it as generic as possible.  I think Jan
> is working on a constructive response that may suggest how to do this.
>
> cheers
>
>
>


-- 
/*************************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 * http://www.coredevelopers.net
 *************************************/

Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Greg Wilkins <gr...@mortbay.com>]

Aaron Mulder wrote:
> Jan (and Greg),
> 	This looks cool.

It's all Jan at the moment - I'm stuck into Jetty5 and making it a bit more
flexible to suit.  But happy to take credit for any of the cool bits :-)
(NB. but I will soon to the clean up of Component and ManagedObject stuff
that I spoke about some time ago).

> 	That said, I'd like to work on centralizing some of the deployment
> logic.  All the work of dealing with deployment plans and tasks is going
> to be fairly common across application module types, and we'll need to
> bring a lot of it together when we deploy an EAR anyway (arranging
> ClassLoaders and identifying context roots and so on).  Also, the JSR-88
> model lets you distribute an application to one or more servers without
> starting it, and the MBeans need to created at distribute time so they can
> be invoked to start it.

I think centralizing logic is a good thing to do, but I am very cautious
about moving webapp specific knowledge out of the webcontainer itself.

The common deployment planning should all be about abstract geronomo
services and not about specific types of services.  Remember that
the webcontainer, the webapp, the webconnector, the request log, etc
are all first class geronimo services and we don't want to have to
move detailed planning for all of these into a centralized spot.

> 	So I'd like to build most of that into the application deployer
> service, and then have the application deployer call out to the
> WebContainer, EJBContainer, etc. at a later stage, more like:
> 
> start(String contextRoot, ClassLoader parent, File warDir, (DD POJO));

This is exactly the sort of API that I would like to avoid.  The deployment
mechanism should only be calling standard JSR77 style start/stop methods
and nothing specific to a webapplication.    I think all these parameters
have better ways of being pased:

  contextRoot - should be obtained from the DDs
  parent - should be the Thread context loader for any call to the service.
  warDir - is a configuration parameter passed during construction of the
           service.
  DD POJO - The API should not reflect our POJO DD's.  A service should be free
            to read the DDs from disk if it want's to.  Of course we want it
            to use the preparsed POJO DD's for efficiency and dynamic deployments,
            but I think that should be an option for a well written service.
            Thus the service should use a DD API to ask for it's POJO DD rather
            have it pushed at it.

> stop(...)
> restart(...)
> 
> 	Does that sound reasonable to you?  Can you help me define what 
> the WebContainer interface should look like for that?  For example:

The webcontainer interface should look like a standard JSR77 lifecycle.
Any bells and whistles we add should be common to all g-services and nothing
should be specific for webapplications.

>  - Should we always unpack a WAR into a temporary dir before handing it
> over, or are you just as happy to get a packed WAR file?

I think unpacking should be the default option.  It can be handled by
the common deployer - but not in terms of war's specifically.  I'd prefer
to see it have a configurable none/shallow/deep unpacking mechanism that
can be applied to arbitrary service bundles.

So I think we should look to moving common code out of the webcontainer
deployer, but let's try to keep it as generic as possible.  I think Jan
is working on a constructive response that may suggest how to do this.

cheers

Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Greg Wilkins <gr...@mortbay.com>]

Greg Wilkins ranted:
> [...]
> So I think the way forward is for:
>   Aaron - can you think how to cast your proposal in terms of generic
>   rather than specific APIs, such that the Web app deployer (where ever 
> that
>   may be) will see the same style of calls for a WAR in EAR deploy as it
>   would for a direct WAR deploy.
> 
>   Jan - can you look at you current code and give more details of the
>   steps & process that could like be given up to a common deployer.

Having just chatted to Jan about this - I think I can say this more
clearly as:

So I think the way forward is to look at the DeploymentPlanner API
and make sure that it conforms to JSR88 (eg at the very least planDeployment
should not plan a start step).

This needs to be done at the DeploymentPlanner level so that all deployers
(service deployer, ear deployer, war deployer) will conform to JSR88.

We then need to look at how one deployment planner can request the
deployment of another unit and for it to supply additional context (eg
for the ear deployer to request a war deployment, but with extra DDs).

Finally, we then need to look at the common handling done by all deployers and
make sure that is implemented only once (ie in an DeploymentPlannerSupport
class or AbstractDeploymentPlanner or as a method of the deployment
controller - whatever).

Thus I think that the code that Aaron is talking about will end up
in the DeploymenPlannerSupport and in an EARDeploymentPlanner.

The code that Jan is talking about ends up in the Webapp deploymentplanner (which
is the WebContainer) and it will use a DeploymentPlannerSupport.
It does not really know or care if it get's called to deploy something
the deployment scanner found or something that the EARDeploymentPlanner requested,
it is all the same to it (except an additional DD will be passed in the context).


cheers

Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Greg Wilkins <gr...@mortbay.com>]

Greg Wilkins ranted:
> [...]
> So I think the way forward is for:
>   Aaron - can you think how to cast your proposal in terms of generic
>   rather than specific APIs, such that the Web app deployer (where ever 
> that
>   may be) will see the same style of calls for a WAR in EAR deploy as it
>   would for a direct WAR deploy.
> 
>   Jan - can you look at you current code and give more details of the
>   steps & process that could like be given up to a common deployer.

Having just chatted to Jan about this - I think I can say this more
clearly as:

So I think the way forward is to look at the DeploymentPlanner API
and make sure that it conforms to JSR88 (eg at the very least planDeployment
should not plan a start step).

This needs to be done at the DeploymentPlanner level so that all deployers
(service deployer, ear deployer, war deployer) will conform to JSR88.

We then need to look at how one deployment planner can request the
deployment of another unit and for it to supply additional context (eg
for the ear deployer to request a war deployment, but with extra DDs).

Finally, we then need to look at the common handling done by all deployers and
make sure that is implemented only once (ie in an DeploymentPlannerSupport
class or AbstractDeploymentPlanner or as a method of the deployment
controller - whatever).

Thus I think that the code that Aaron is talking about will end up
in the DeploymenPlannerSupport and in an EARDeploymentPlanner.

The code that Jan is talking about ends up in the Webapp deploymentplanner (which
is the WebContainer) and it will use a DeploymentPlannerSupport.
It does not really know or care if it get's called to deploy something
the deployment scanner found or something that the EARDeploymentPlanner requested,
it is all the same to it (except an additional DD will be passed in the context).


cheers

Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Greg Wilkins <gr...@mortbay.com>]

Arron & Jan,

I think you both are saying pretty much the same thing - with two points
of contention:


1) Who has the flow of control and call back on the other the common/specific
    behaviour.

Jan's

    distribute (URL url)

method is really the pretty much the same thing as Aaron's

    validateDeployment(URL, EAR-POJOs, WAR-POJOs)

the difference being the former gives control to the specific processing
and calls will be made to access generic processing.   The later has control
with the generic processing and calls are made for specific information or
steps.

I think the reason that I like the former better, is that a) it is more
flexible and b) it can be called directly from the deployment controller.

I think it should always be called from the deployment controller, so that
we have the same handling for deploying a simple WAR as we do deploying a
WAR from within an EAR.

One of the use-cases we have is having multiple WebContainers deployed and
needing to workout which one to use to deploy a particular WAR.  The way that
was intended to work is that the deployment controller would call each
deployer in turn saying "can you deploy this".  It is the webdeployer
itself that will examine the DD's to work out if this webapp is for it.

So for this to work from the EAR deployer, it needs to use the deployment
controller to deploy the WAR's - rather than calling a specific webdeployer
directly.

Thus I think there is a case for the EAR deployer using the generic
APIs to call deploy the war, rather than calling it directly.   Of course
it would have to make the ear DD's available to the deployment context
as Jan suggested.


2) Is the API generic or webapp specific?

Aaron has suggested
    validateDeployment(URL, EAR-POJOs, WAR-POJOs)

If we combine the EAR-PJO and WAR-POJO into a DeploymentContext and
make validateDeployment a standard method called by the DeploymentController
then I think the two approaches are getting to be pretty much the same thing.

For more flexibility we could change this method to just deploy or distribute
and what Aaron suggests as

   - for each web app in EAR:
     - common deployer calls WebContainer to validate a web app,
     - common deployer gets web MBean class from WebContainer
     - common deployer creates web app MBean w/class & ObjectName provided
     - common deployer sets properties on web app MBean
     - common deployer tells web app MBean to generate custom code

becomes:

   - for each web app in EAR:
     - ear deployer calls deployer controller with it's deployment context
      - deployer controller calls deploy on EACH Web Deployer
        - Web Deployer examines DDs to work out if it can deploy this war
        - Web Deployer calls common deployer to create web app MBean
            - common deployer sets properties on web app MBean
        - Web Deployer calls/returns to common deployer
            - common deployer tells web app MBEan to generate custom code (what is
              this step anyway???)


A few more comments in-line:


Aaron Mulder wrote:

> 	I'm arguing to split it up, so we do much of the common reusable 
> tasks in a central deployer and then dispatch to a specific deployer for 
> the truly custom details.

I think you both are saying that.  So it is just the contract and the
path between the common and the specific we need to agree.


>>1. JSR88 deployment lifecycle vs geronimo hot deploy lifecycle
>  
> 	My feeling is that distribute can be done nearly entirely by the
> common code, with 1 or 2 calls to the WebContainer.  

That should be able to work the other way, with the web deployer doing
the deployment with 1 or 2 calls to the common code.   I think there
is a case for the increased flexibility and generics of this approach.


> Let's look at the
> case of an EAR.  Something needs to set up a series of ClassLoaders,
> create one MBean for the EAR and another per module, validate all the
> modules, and generate container-specific classes.  There are a number of 
> steps invokving Goals and Tasks and Plans.  I think the application 
> deployer could do everything listed above, with calls to the WebContainer 
> to:
> 
>  - get the AppModule MBean class name (to use for a createMBean task)
>  - validate the application (given URL, DD, etc.)
>  - generate container classes (which I think amounts to precompiling JSPs 
> in the case of a web container)
> 
> 	If there was other web-specific logic, it would presumably happen 
> in the postRegister event on the application MBean.  I think these same 3 
> steps would work for implementing "distribute" for every container type.  
> Most of the container-specific work seems to be in "start", which is 
> implemented by the container-specific app module MBean anyway.
> 
> 
>>2. typed deployers
>>the central deployment mechanism should only be responsible for 
>>detecting things to be deployed, and arranging for distribute(), 
>>start(), undeploy() or whatever to be called on the appropriate 
>>deployer. Typed deployers are necessary because the things that are 
>>being deployed are different. Sure, they might go through a certain 
>>amount of common steps, and these can be abstracted for re-use within 
>>each deployer, but it does not follow that therefore there should only 
>>be one deployer for everything. For example, the web deployer, and only 
>>the web deployer, should be responsible for determining such things as 
>>the context path of a web application. This is very webby specific and 
>>the natural place for this is in a web module. The information that is 
>>used to determine that path can come from many sources: the name of the 
>>directory or war, a tag in an application DD, or an override in a 
>>geronimo-web DD, but the algorithm for choosing is specific to web 
>>deployments only.
> 
> 
> 	I agree with the spirit but potentially disagree with the example.  
> I do not believe that the application deployer should instruct the web
> deployer on how to set up a servlet context or something like that.  As 
> above, though, I think it can take most of the "distribute" work off your 
> hands, except for a couple container-specific callbacks.  And startup is 
> in your court anyway, thanks to JSR-77.
> 	As far as the context root is concerned, I don't want the web
> container groping for content outside the web app -- the last things we
> want is inadvertent dependencies where the web container penetrates its
> interface to root around in the guts of the server or the application.  

Something has to grope through all the DD's and work out the context path.
That is completely webapp specific logic and so it should be in the
webapp deployer.


> So I thought it would be easy enough for the common deployer to do that
> calculation for you (after all, it has the EAR DD, the file name, etc.).  
> But it doesn't *have* to be done that way -- we could instead pass the EAR
> DD POJOs to the web container along with the WAR DD POJOs and let you do
> the calculation yourself.

I think this is the solution Jan was suggestion.  That all the DD's get
passed in a DeploymentContext to the specific Deployer.  It is it's
job to grope about all those DD's and resolve any configuration such as
context path that can come from multiple sources.



So I think the way forward is for:
   Aaron - can you think how to cast your proposal in terms of generic
   rather than specific APIs, such that the Web app deployer (where ever that
   may be) will see the same style of calls for a WAR in EAR deploy as it
   would for a direct WAR deploy.

   Jan - can you look at you current code and give more details of the
   steps & process that could like be given up to a common deployer.

Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Greg Wilkins <gr...@mortbay.com>]

Arron & Jan,

I think you both are saying pretty much the same thing - with two points
of contention:


1) Who has the flow of control and call back on the other the common/specific
    behaviour.

Jan's

    distribute (URL url)

method is really the pretty much the same thing as Aaron's

    validateDeployment(URL, EAR-POJOs, WAR-POJOs)

the difference being the former gives control to the specific processing
and calls will be made to access generic processing.   The later has control
with the generic processing and calls are made for specific information or
steps.

I think the reason that I like the former better, is that a) it is more
flexible and b) it can be called directly from the deployment controller.

I think it should always be called from the deployment controller, so that
we have the same handling for deploying a simple WAR as we do deploying a
WAR from within an EAR.

One of the use-cases we have is having multiple WebContainers deployed and
needing to workout which one to use to deploy a particular WAR.  The way that
was intended to work is that the deployment controller would call each
deployer in turn saying "can you deploy this".  It is the webdeployer
itself that will examine the DD's to work out if this webapp is for it.

So for this to work from the EAR deployer, it needs to use the deployment
controller to deploy the WAR's - rather than calling a specific webdeployer
directly.

Thus I think there is a case for the EAR deployer using the generic
APIs to call deploy the war, rather than calling it directly.   Of course
it would have to make the ear DD's available to the deployment context
as Jan suggested.


2) Is the API generic or webapp specific?

Aaron has suggested
    validateDeployment(URL, EAR-POJOs, WAR-POJOs)

If we combine the EAR-PJO and WAR-POJO into a DeploymentContext and
make validateDeployment a standard method called by the DeploymentController
then I think the two approaches are getting to be pretty much the same thing.

For more flexibility we could change this method to just deploy or distribute
and what Aaron suggests as

   - for each web app in EAR:
     - common deployer calls WebContainer to validate a web app,
     - common deployer gets web MBean class from WebContainer
     - common deployer creates web app MBean w/class & ObjectName provided
     - common deployer sets properties on web app MBean
     - common deployer tells web app MBean to generate custom code

becomes:

   - for each web app in EAR:
     - ear deployer calls deployer controller with it's deployment context
      - deployer controller calls deploy on EACH Web Deployer
        - Web Deployer examines DDs to work out if it can deploy this war
        - Web Deployer calls common deployer to create web app MBean
            - common deployer sets properties on web app MBean
        - Web Deployer calls/returns to common deployer
            - common deployer tells web app MBEan to generate custom code (what is
              this step anyway???)


A few more comments in-line:


Aaron Mulder wrote:

> 	I'm arguing to split it up, so we do much of the common reusable 
> tasks in a central deployer and then dispatch to a specific deployer for 
> the truly custom details.

I think you both are saying that.  So it is just the contract and the
path between the common and the specific we need to agree.


>>1. JSR88 deployment lifecycle vs geronimo hot deploy lifecycle
>  
> 	My feeling is that distribute can be done nearly entirely by the
> common code, with 1 or 2 calls to the WebContainer.  

That should be able to work the other way, with the web deployer doing
the deployment with 1 or 2 calls to the common code.   I think there
is a case for the increased flexibility and generics of this approach.


> Let's look at the
> case of an EAR.  Something needs to set up a series of ClassLoaders,
> create one MBean for the EAR and another per module, validate all the
> modules, and generate container-specific classes.  There are a number of 
> steps invokving Goals and Tasks and Plans.  I think the application 
> deployer could do everything listed above, with calls to the WebContainer 
> to:
> 
>  - get the AppModule MBean class name (to use for a createMBean task)
>  - validate the application (given URL, DD, etc.)
>  - generate container classes (which I think amounts to precompiling JSPs 
> in the case of a web container)
> 
> 	If there was other web-specific logic, it would presumably happen 
> in the postRegister event on the application MBean.  I think these same 3 
> steps would work for implementing "distribute" for every container type.  
> Most of the container-specific work seems to be in "start", which is 
> implemented by the container-specific app module MBean anyway.
> 
> 
>>2. typed deployers
>>the central deployment mechanism should only be responsible for 
>>detecting things to be deployed, and arranging for distribute(), 
>>start(), undeploy() or whatever to be called on the appropriate 
>>deployer. Typed deployers are necessary because the things that are 
>>being deployed are different. Sure, they might go through a certain 
>>amount of common steps, and these can be abstracted for re-use within 
>>each deployer, but it does not follow that therefore there should only 
>>be one deployer for everything. For example, the web deployer, and only 
>>the web deployer, should be responsible for determining such things as 
>>the context path of a web application. This is very webby specific and 
>>the natural place for this is in a web module. The information that is 
>>used to determine that path can come from many sources: the name of the 
>>directory or war, a tag in an application DD, or an override in a 
>>geronimo-web DD, but the algorithm for choosing is specific to web 
>>deployments only.
> 
> 
> 	I agree with the spirit but potentially disagree with the example.  
> I do not believe that the application deployer should instruct the web
> deployer on how to set up a servlet context or something like that.  As 
> above, though, I think it can take most of the "distribute" work off your 
> hands, except for a couple container-specific callbacks.  And startup is 
> in your court anyway, thanks to JSR-77.
> 	As far as the context root is concerned, I don't want the web
> container groping for content outside the web app -- the last things we
> want is inadvertent dependencies where the web container penetrates its
> interface to root around in the guts of the server or the application.  

Something has to grope through all the DD's and work out the context path.
That is completely webapp specific logic and so it should be in the
webapp deployer.


> So I thought it would be easy enough for the common deployer to do that
> calculation for you (after all, it has the EAR DD, the file name, etc.).  
> But it doesn't *have* to be done that way -- we could instead pass the EAR
> DD POJOs to the web container along with the WAR DD POJOs and let you do
> the calculation yourself.

I think this is the solution Jan was suggestion.  That all the DD's get
passed in a DeploymentContext to the specific Deployer.  It is it's
job to grope about all those DD's and resolve any configuration such as
context path that can come from multiple sources.



So I think the way forward is for:
   Aaron - can you think how to cast your proposal in terms of generic
   rather than specific APIs, such that the Web app deployer (where ever that
   may be) will see the same style of calls for a WAR in EAR deploy as it
   would for a direct WAR deploy.

   Jan - can you look at you current code and give more details of the
   steps & process that could like be given up to a common deployer.

Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Greg Wilkins <gr...@mortbay.com>]

Aaron Mulder wrote:

> P.S. What good is all this flexibility when we know we'll have exactly
> EARs, WARs, EJB JARs, and RARs, and we need to specifically arrange
> ClassLoaders across them, and there are hardcoded constants for those
> module types in the J2EE 1.4 API?  It's not like you could/would just drop
> in a new xAR archive/component type.

Expect the unexpected.

We are already deploy services (eg WebContainer) and subservices (WebConnector,
RequestLog). So it is not just EARs, WARs, EJB JARs, and RARs.  I hope
in future to be deploying lots of other subservices like session distributors
etc.

If we have an extensible deployment mechanism then it can be extended
in all sorts of wonderful (and horrible) ways.

If we don't have an extensible deployment mechanism then we will only
ever deploy EARs, WARs, EJB JARs, and RARs.

Besides, I think having separate deployment classes for the different
things to deploy is good separation of concerns anyway - even if it was
not made extensible.

Note that I don't think that common deployment behaviour can go in an
Abstract base class, as we already have AbstractManagedObject that services
need to extend.  The common deployment behaviour will probly need to go
in a DeploymentSupport class or on the DeploymentController itself.


cheers

Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Aaron Mulder <am...@alumni.princeton.edu>]

Just to kind of recap where we are (I think):

 - I favor a central deployer which delegates only where necessary
 - Jan favors separate deployers per module, with a common base class
 - We seem to be more or less in agreement on the API, whichever way it 
ends up being implemented
 - Gianny was going to put together some sample code

I think I'm fine going ahead with something more like what Jan is
proposing, though I'm still not convinced that it's the best approach 
(commentary below).  Gianny, are you still going to be putting out a 
proposal/sample?

In the mean time, I'm working on getting the JSR-88 implementation up to 
speed with web modules.  It's close, but not quite there (primarily, we 
need to be able to write the DD POJOs out to an XML file).  You can edit 
the geronimo-web.xml DD with the command line deployer, but not save it 
yet.  :)

Aaron

P.S. What good is all this flexibility when we know we'll have exactly
EARs, WARs, EJB JARs, and RARs, and we need to specifically arrange
ClassLoaders across them, and there are hardcoded constants for those
module types in the J2EE 1.4 API?  It's not like you could/would just drop
in a new xAR archive/component type.

On Mon, 6 Oct 2003, Jan Bartel wrote:
> I am definitely in favour of a central controller, but not a central 
> deployer. The DeploymentController that we have now is the only central 
> entity that is necessary. In other words, something whose only task is 
> to notice that there are things that need to be deployed, undeployed or 
> redeployed. The DeploymentController needs to be able to support both 
> the geronimo hot deploy directory and also deployments coming from a 
> JSR88 tool.
> 
> > 
> > 
> >>1. JSR88 deployment lifecycle vs geronimo hot deploy lifecycle
> > 
> > 
> > 	My feeling is that distribute can be done nearly entirely by the
> > common code, with 1 or 2 calls to the WebContainer.  Let's look at the
> > case of an EAR.  Something needs to set up a series of ClassLoaders,
> > create one MBean for the EAR and another per module, validate all the
> > modules, and generate container-specific classes.  There are a number of 
> > steps invokving Goals and Tasks and Plans.  I think the application 
> > deployer could do everything listed above, with calls to the WebContainer 
> > to:
> > 
> >  - get the AppModule MBean class name (to use for a createMBean task)
> >  - validate the application (given URL, DD, etc.)
> >  - generate container classes (which I think amounts to precompiling JSPs 
> > in the case of a web container)
> > 
> > 	If there was other web-specific logic, it would presumably happen 
> > in the postRegister event on the application MBean.  I think these same 3 
> > steps would work for implementing "distribute" for every container type.  
> > Most of the container-specific work seems to be in "start", which is 
> > implemented by the container-specific app module MBean anyway.
> In my reply to Gianny's email, I've said what I think is the biggest 
> weakness with the central deployer approach: that is the lack of 
> flexibility. To add support for a new deployable type, we'd have to 
> modify the central deployer code, adding yet more "if then else" clauses 
> each time. By keeping individual deployers (but that reuse common 
> deployment code perhaps from a baseclass) we gain a lot of flexibility. 
> For example, with individual deployers, we are able to hot deploy a new 
> deployer and introduce support for a brand new deployment type into a 
> running geronimo instance.
> 
> 
> >>2. typed deployers
> >>the central deployment mechanism should only be responsible for 
> >>detecting things to be deployed, and arranging for distribute(), 
> >>start(), undeploy() or whatever to be called on the appropriate 
> >>deployer. Typed deployers are necessary because the things that are 
> >>being deployed are different. Sure, they might go through a certain 
> >>amount of common steps, and these can be abstracted for re-use within 
> >>each deployer, but it does not follow that therefore there should only 
> >>be one deployer for everything. For example, the web deployer, and only 
> >>the web deployer, should be responsible for determining such things as 
> >>the context path of a web application. This is very webby specific and 
> >>the natural place for this is in a web module. The information that is 
> >>used to determine that path can come from many sources: the name of the 
> >>directory or war, a tag in an application DD, or an override in a 
> >>geronimo-web DD, but the algorithm for choosing is specific to web 
> >>deployments only.
> > 
> > 
> > 	I agree with the spirit but potentially disagree with the example.  
> > I do not believe that the application deployer should instruct the web
> > deployer on how to set up a servlet context or something like that.  As 
> > above, though, I think it can take most of the "distribute" work off your 
> > hands, except for a couple container-specific callbacks.  And startup is 
> > in your court anyway, thanks to JSR-77.
> > 	As far as the context root is concerned, I don't want the web
> > container groping for content outside the web app -- the last things we
> > want is inadvertent dependencies where the web container penetrates its
> > interface to root around in the guts of the server or the application.  
> > So I thought it would be easy enough for the common deployer to do that
> > calculation for you (after all, it has the EAR DD, the file name, etc.).  
> > But it doesn't *have* to be done that way -- we could instead pass the EAR
> > DD POJOs to the web container along with the WAR DD POJOs and let you do
> > the calculation yourself.
> I'd much prefer that the interface contract to the deployers contained 
> the DD pojos (preferably as part of a DeploymentContext, but that is 
> covered in other threads), so that the individual deployer can extract 
> whatever information it requires. That allows for maximum flexibility.
> 
> > 
> > 	Thinking back, I seem to have overlooked how the ObjectName will 
> > be generated.  Personally I would rather have standard application module 
> > ObjectNames no matter what container is plugged in, so I'd rather see 
> > "geronimo.deployment:role=WebApplication,instance=(unique ID)" instead of 
> > "jetty:...".  So I'd prefer to add a 4th method "getUniqueID" to the 3 
> > listed above.  But if you feel strongly it could just be "getObjectName" 
> > and you can construct a Jetty name instead.
> As Gianny has pointed out, JSR77 seems to have something to say about 
> acceptable names, so we'll stick to those. I just blindly followed the 
> naming precedent that had been set in the "hack" Jetty integration. Now 
> I know better :-)
> 
> 
> >>3. ear/war relationship
> >>wars can be deployed standalone, or bundled as part of an ear. In the 
> >>latter case, then some of the deployment information for the war is 
> >>contained in the deployment descriptor for the ear, and as you point 
> >>out, the classloader hierarchy needs to be established. I think this 
> >>should be handled as much as possible via the normal deployment mechanism.
> >>
> >>To that end, I suggest we augment the signature of the deploy, 
> >>distribute, undeploy etc methods with another parameter: 
> >>DeploymentContext. This context can contain deployment descriptor POJOs 
> >>or xml, or classloader objects or perhaps state information. Anything 
> >>that defines the context in which the deployment is taking place.
> > 
> > 
> > 	Well, I agree that we need to get more information to each 
> > container.
> > 
> > 	Let me propose a revised base WebContainer and WebApplication, and
> > let me know what you think.  I believe this should leave the bulk of the
> > "geronimo kernel"-specific logic in the central deployer, and the bulk of
> > the module-specific logic in the container, which seems to me like the
> > right split:
> > 
> > abstract class AbstractWebContainerMBean {
> >   // returns i.e. JettyWebApplication
> >   public abstract String getModuleMBeanClass()
> > 
> >   // validates the deployment and returns an ObjectName if valid
> >   public abstract ObjectName validateDeployment(URL, EAR-POJOs, WAR-POJOs)
> > }
> > 
> > abstract class AbstractWebApplicationMBean
> >   public void setURL(URL)
> >   public void setBaseClassLoader(ClassLoader/ClassSpace)
> >   public void setEARDeploymentInfo(EAR-POJOs)
> >   public void setWARDeploymentInfo(WAR-POJOs)
> > 
> >   // will be called during distribution process; can precompile JSPs
> >   public abstract void generateContainerClasses()
> > }
> > 
> > 	So now the sequence is something like this:
> > 
> >  - common deployer identifies app and modules
> >  - (something) validates EAR
> >  - common deployer creates app MBean
> >  - for each RAR in EAR:
> >    - common deployer calls ConnectorContainer to validate a RAR, gets
> >      ObjectName for valid ones
> >    - common deployer gets connector MBean class from ConnectorContainer
> >    - common deployer creates Connector MBean w/class & ObjectName provided
> >    - common deployer sets properties on Connector MBean
> >    - common deployer tells Connector MBean to generate custom code
> >    - common deployer gets ClassSpace from Connector MBean
> >  - for each EJB JAR in EAR:
> >    - common deployer calls EJBContainer to validate a JAR, gets
> >      ObjectName for valid ones
> >    - common deployer gets EJB JAR MBean class from EJBContainer
> >    - common deployer creates EJB JAR MBean w/class & ObjectName provided
> >    - common deployer sets properties on EJB JAR MBean
> >    - common deployer tells EJB JAR MBean to generate custom code
> >    - common deployer gets ClassSpace from EJB JAR MBean
> >  - for each web app in EAR:
> >    - common deployer calls WebContainer to validate a web app, gets
> >      ObjectName for valid ones
> >    - common deployer gets web MBean class from WebContainer
> >    - common deployer creates web app MBean w/class & ObjectName provided
> >    - common deployer sets properties on web app MBean
> >    - common deployer tells web app MBean to generate custom code
> 
> As I mentioned above, one of the major problems with this approach
> is the tight coupling between the EARDeployer and every other deployer
> in the system. A looser coupling, whereby the EARDeployer, WARDeployer,
> RARDeployer, ServiceDeployer and XYZDeployer all re-use common Deployer
> code (maybe as a base class or maybe as a delegate), but all communicate 
> through a standard set of JSR77/JSR88 style methods (JSR77: start/stop 
> etc, JSR88: distribute, undeploy etc) mediated by the 
> DeploymentController, gives us:
> 
>   - maximum flexibility to easily introduce support for new deployment
>     types
> 
>   - uniformity of control flows
> 
>   - uses existing mechanisms for co-ordinating deployment, eg checking if
>     a deployment task can proceed based on the outcome of other tasks,
>     suspending deployments for which no appropriate deployer can be
>     found, retrying failed deployments etc etc
> 
> 
> 
> > Note that all the deployment plans and goals and tasks are managed by 
> > the common deployer -- when it says "creates web app MBean" and "sets 
> > properties on web app MBean" it really means "registers a task in the 
> > deployment plan to..."  So the WebContainer is doing web stuff not 
> > deployment plan stuff.
> > 
> > Then at start time, there are just a bunch of JSR-77 start() commands
> > executed, so the detailed startup logic is left to the module.
> > 
> > You seemed to be saying that there were web-specific steps that either the 
> > common deployer would do inappropriately or the web container wouldn't be 
> > given the opportunity to do -- would that still be the case?
> 
> 
> cheers,
> Jan
> 

Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Jan Bartel <ja...@mortbay.com>]

Aaron,

>>I agree there may be common code that can be extracted for the 
>>deployment of various j2ee artifacts such as ears and wars. This will 
>>come out as development continues and matures. However, there will 
>>inevitably be differences between deploying say, a war, and a rar. It 
>>seems to me almost as if you are arguing for one big happy generic 
>>"application" deployer rather than specific deployers. If so, then I 
>>don't agree with that approach.
> 
> 
> 	I'm arguing to split it up, so we do much of the common reusable 
> tasks in a central deployer and then dispatch to a specific deployer for 
> the truly custom details.
I am definitely in favour of a central controller, but not a central 
deployer. The DeploymentController that we have now is the only central 
entity that is necessary. In other words, something whose only task is 
to notice that there are things that need to be deployed, undeployed or 
redeployed. The DeploymentController needs to be able to support both 
the geronimo hot deploy directory and also deployments coming from a 
JSR88 tool.

> 
> 
>>1. JSR88 deployment lifecycle vs geronimo hot deploy lifecycle
> 
> 
> 	My feeling is that distribute can be done nearly entirely by the
> common code, with 1 or 2 calls to the WebContainer.  Let's look at the
> case of an EAR.  Something needs to set up a series of ClassLoaders,
> create one MBean for the EAR and another per module, validate all the
> modules, and generate container-specific classes.  There are a number of 
> steps invokving Goals and Tasks and Plans.  I think the application 
> deployer could do everything listed above, with calls to the WebContainer 
> to:
> 
>  - get the AppModule MBean class name (to use for a createMBean task)
>  - validate the application (given URL, DD, etc.)
>  - generate container classes (which I think amounts to precompiling JSPs 
> in the case of a web container)
> 
> 	If there was other web-specific logic, it would presumably happen 
> in the postRegister event on the application MBean.  I think these same 3 
> steps would work for implementing "distribute" for every container type.  
> Most of the container-specific work seems to be in "start", which is 
> implemented by the container-specific app module MBean anyway.
In my reply to Gianny's email, I've said what I think is the biggest 
weakness with the central deployer approach: that is the lack of 
flexibility. To add support for a new deployable type, we'd have to 
modify the central deployer code, adding yet more "if then else" clauses 
each time. By keeping individual deployers (but that reuse common 
deployment code perhaps from a baseclass) we gain a lot of flexibility. 
For example, with individual deployers, we are able to hot deploy a new 
deployer and introduce support for a brand new deployment type into a 
running geronimo instance.


>>2. typed deployers
>>the central deployment mechanism should only be responsible for 
>>detecting things to be deployed, and arranging for distribute(), 
>>start(), undeploy() or whatever to be called on the appropriate 
>>deployer. Typed deployers are necessary because the things that are 
>>being deployed are different. Sure, they might go through a certain 
>>amount of common steps, and these can be abstracted for re-use within 
>>each deployer, but it does not follow that therefore there should only 
>>be one deployer for everything. For example, the web deployer, and only 
>>the web deployer, should be responsible for determining such things as 
>>the context path of a web application. This is very webby specific and 
>>the natural place for this is in a web module. The information that is 
>>used to determine that path can come from many sources: the name of the 
>>directory or war, a tag in an application DD, or an override in a 
>>geronimo-web DD, but the algorithm for choosing is specific to web 
>>deployments only.
> 
> 
> 	I agree with the spirit but potentially disagree with the example.  
> I do not believe that the application deployer should instruct the web
> deployer on how to set up a servlet context or something like that.  As 
> above, though, I think it can take most of the "distribute" work off your 
> hands, except for a couple container-specific callbacks.  And startup is 
> in your court anyway, thanks to JSR-77.
> 	As far as the context root is concerned, I don't want the web
> container groping for content outside the web app -- the last things we
> want is inadvertent dependencies where the web container penetrates its
> interface to root around in the guts of the server or the application.  
> So I thought it would be easy enough for the common deployer to do that
> calculation for you (after all, it has the EAR DD, the file name, etc.).  
> But it doesn't *have* to be done that way -- we could instead pass the EAR
> DD POJOs to the web container along with the WAR DD POJOs and let you do
> the calculation yourself.
I'd much prefer that the interface contract to the deployers contained 
the DD pojos (preferably as part of a DeploymentContext, but that is 
covered in other threads), so that the individual deployer can extract 
whatever information it requires. That allows for maximum flexibility.

> 
> 	Thinking back, I seem to have overlooked how the ObjectName will 
> be generated.  Personally I would rather have standard application module 
> ObjectNames no matter what container is plugged in, so I'd rather see 
> "geronimo.deployment:role=WebApplication,instance=(unique ID)" instead of 
> "jetty:...".  So I'd prefer to add a 4th method "getUniqueID" to the 3 
> listed above.  But if you feel strongly it could just be "getObjectName" 
> and you can construct a Jetty name instead.
As Gianny has pointed out, JSR77 seems to have something to say about 
acceptable names, so we'll stick to those. I just blindly followed the 
naming precedent that had been set in the "hack" Jetty integration. Now 
I know better :-)


>>3. ear/war relationship
>>wars can be deployed standalone, or bundled as part of an ear. In the 
>>latter case, then some of the deployment information for the war is 
>>contained in the deployment descriptor for the ear, and as you point 
>>out, the classloader hierarchy needs to be established. I think this 
>>should be handled as much as possible via the normal deployment mechanism.
>>
>>To that end, I suggest we augment the signature of the deploy, 
>>distribute, undeploy etc methods with another parameter: 
>>DeploymentContext. This context can contain deployment descriptor POJOs 
>>or xml, or classloader objects or perhaps state information. Anything 
>>that defines the context in which the deployment is taking place.
> 
> 
> 	Well, I agree that we need to get more information to each 
> container.
> 
> 	Let me propose a revised base WebContainer and WebApplication, and
> let me know what you think.  I believe this should leave the bulk of the
> "geronimo kernel"-specific logic in the central deployer, and the bulk of
> the module-specific logic in the container, which seems to me like the
> right split:
> 
> abstract class AbstractWebContainerMBean {
>   // returns i.e. JettyWebApplication
>   public abstract String getModuleMBeanClass()
> 
>   // validates the deployment and returns an ObjectName if valid
>   public abstract ObjectName validateDeployment(URL, EAR-POJOs, WAR-POJOs)
> }
> 
> abstract class AbstractWebApplicationMBean
>   public void setURL(URL)
>   public void setBaseClassLoader(ClassLoader/ClassSpace)
>   public void setEARDeploymentInfo(EAR-POJOs)
>   public void setWARDeploymentInfo(WAR-POJOs)
> 
>   // will be called during distribution process; can precompile JSPs
>   public abstract void generateContainerClasses()
> }
> 
> 	So now the sequence is something like this:
> 
>  - common deployer identifies app and modules
>  - (something) validates EAR
>  - common deployer creates app MBean
>  - for each RAR in EAR:
>    - common deployer calls ConnectorContainer to validate a RAR, gets
>      ObjectName for valid ones
>    - common deployer gets connector MBean class from ConnectorContainer
>    - common deployer creates Connector MBean w/class & ObjectName provided
>    - common deployer sets properties on Connector MBean
>    - common deployer tells Connector MBean to generate custom code
>    - common deployer gets ClassSpace from Connector MBean
>  - for each EJB JAR in EAR:
>    - common deployer calls EJBContainer to validate a JAR, gets
>      ObjectName for valid ones
>    - common deployer gets EJB JAR MBean class from EJBContainer
>    - common deployer creates EJB JAR MBean w/class & ObjectName provided
>    - common deployer sets properties on EJB JAR MBean
>    - common deployer tells EJB JAR MBean to generate custom code
>    - common deployer gets ClassSpace from EJB JAR MBean
>  - for each web app in EAR:
>    - common deployer calls WebContainer to validate a web app, gets
>      ObjectName for valid ones
>    - common deployer gets web MBean class from WebContainer
>    - common deployer creates web app MBean w/class & ObjectName provided
>    - common deployer sets properties on web app MBean
>    - common deployer tells web app MBean to generate custom code

As I mentioned above, one of the major problems with this approach
is the tight coupling between the EARDeployer and every other deployer
in the system. A looser coupling, whereby the EARDeployer, WARDeployer,
RARDeployer, ServiceDeployer and XYZDeployer all re-use common Deployer
code (maybe as a base class or maybe as a delegate), but all communicate 
through a standard set of JSR77/JSR88 style methods (JSR77: start/stop 
etc, JSR88: distribute, undeploy etc) mediated by the 
DeploymentController, gives us:

  - maximum flexibility to easily introduce support for new deployment
    types

  - uniformity of control flows

  - uses existing mechanisms for co-ordinating deployment, eg checking if
    a deployment task can proceed based on the outcome of other tasks,
    suspending deployments for which no appropriate deployer can be
    found, retrying failed deployments etc etc



> Note that all the deployment plans and goals and tasks are managed by 
> the common deployer -- when it says "creates web app MBean" and "sets 
> properties on web app MBean" it really means "registers a task in the 
> deployment plan to..."  So the WebContainer is doing web stuff not 
> deployment plan stuff.
> 
> Then at start time, there are just a bunch of JSR-77 start() commands
> executed, so the detailed startup logic is left to the module.
> 
> You seemed to be saying that there were web-specific steps that either the 
> common deployer would do inappropriately or the web container wouldn't be 
> given the opportunity to do -- would that still be the case?


cheers,
Jan

Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Aaron Mulder <am...@alumni.princeton.edu>]

	Okay, this is a bunch of inline responses, with a specific code & 
procedure proposal at the very end:

On Sat, 4 Oct 2003, Jan Bartel wrote:
> I agree there may be common code that can be extracted for the 
> deployment of various j2ee artifacts such as ears and wars. This will 
> come out as development continues and matures. However, there will 
> inevitably be differences between deploying say, a war, and a rar. It 
> seems to me almost as if you are arguing for one big happy generic 
> "application" deployer rather than specific deployers. If so, then I 
> don't agree with that approach.

	I'm arguing to split it up, so we do much of the common reusable 
tasks in a central deployer and then dispatch to a specific deployer for 
the truly custom details.

> 1. JSR88 deployment lifecycle vs geronimo hot deploy lifecycle

	My feeling is that distribute can be done nearly entirely by the
common code, with 1 or 2 calls to the WebContainer.  Let's look at the
case of an EAR.  Something needs to set up a series of ClassLoaders,
create one MBean for the EAR and another per module, validate all the
modules, and generate container-specific classes.  There are a number of 
steps invokving Goals and Tasks and Plans.  I think the application 
deployer could do everything listed above, with calls to the WebContainer 
to:

 - get the AppModule MBean class name (to use for a createMBean task)
 - validate the application (given URL, DD, etc.)
 - generate container classes (which I think amounts to precompiling JSPs 
in the case of a web container)

	If there was other web-specific logic, it would presumably happen 
in the postRegister event on the application MBean.  I think these same 3 
steps would work for implementing "distribute" for every container type.  
Most of the container-specific work seems to be in "start", which is 
implemented by the container-specific app module MBean anyway.

> 2. typed deployers
> the central deployment mechanism should only be responsible for 
> detecting things to be deployed, and arranging for distribute(), 
> start(), undeploy() or whatever to be called on the appropriate 
> deployer. Typed deployers are necessary because the things that are 
> being deployed are different. Sure, they might go through a certain 
> amount of common steps, and these can be abstracted for re-use within 
> each deployer, but it does not follow that therefore there should only 
> be one deployer for everything. For example, the web deployer, and only 
> the web deployer, should be responsible for determining such things as 
> the context path of a web application. This is very webby specific and 
> the natural place for this is in a web module. The information that is 
> used to determine that path can come from many sources: the name of the 
> directory or war, a tag in an application DD, or an override in a 
> geronimo-web DD, but the algorithm for choosing is specific to web 
> deployments only.

	I agree with the spirit but potentially disagree with the example.  
I do not believe that the application deployer should instruct the web
deployer on how to set up a servlet context or something like that.  As 
above, though, I think it can take most of the "distribute" work off your 
hands, except for a couple container-specific callbacks.  And startup is 
in your court anyway, thanks to JSR-77.
	As far as the context root is concerned, I don't want the web
container groping for content outside the web app -- the last things we
want is inadvertent dependencies where the web container penetrates its
interface to root around in the guts of the server or the application.  
So I thought it would be easy enough for the common deployer to do that
calculation for you (after all, it has the EAR DD, the file name, etc.).  
But it doesn't *have* to be done that way -- we could instead pass the EAR
DD POJOs to the web container along with the WAR DD POJOs and let you do
the calculation yourself.

	Thinking back, I seem to have overlooked how the ObjectName will 
be generated.  Personally I would rather have standard application module 
ObjectNames no matter what container is plugged in, so I'd rather see 
"geronimo.deployment:role=WebApplication,instance=(unique ID)" instead of 
"jetty:...".  So I'd prefer to add a 4th method "getUniqueID" to the 3 
listed above.  But if you feel strongly it could just be "getObjectName" 
and you can construct a Jetty name instead.

> 3. ear/war relationship
> wars can be deployed standalone, or bundled as part of an ear. In the 
> latter case, then some of the deployment information for the war is 
> contained in the deployment descriptor for the ear, and as you point 
> out, the classloader hierarchy needs to be established. I think this 
> should be handled as much as possible via the normal deployment mechanism.
> 
> To that end, I suggest we augment the signature of the deploy, 
> distribute, undeploy etc methods with another parameter: 
> DeploymentContext. This context can contain deployment descriptor POJOs 
> or xml, or classloader objects or perhaps state information. Anything 
> that defines the context in which the deployment is taking place.

	Well, I agree that we need to get more information to each 
container.

	Let me propose a revised base WebContainer and WebApplication, and
let me know what you think.  I believe this should leave the bulk of the
"geronimo kernel"-specific logic in the central deployer, and the bulk of
the module-specific logic in the container, which seems to me like the
right split:

abstract class AbstractWebContainerMBean {
  // returns i.e. JettyWebApplication
  public abstract String getModuleMBeanClass()

  // validates the deployment and returns an ObjectName if valid
  public abstract ObjectName validateDeployment(URL, EAR-POJOs, WAR-POJOs)
}

abstract class AbstractWebApplicationMBean
  public void setURL(URL)
  public void setBaseClassLoader(ClassLoader/ClassSpace)
  public void setEARDeploymentInfo(EAR-POJOs)
  public void setWARDeploymentInfo(WAR-POJOs)

  // will be called during distribution process; can precompile JSPs
  public abstract void generateContainerClasses()
}

	So now the sequence is something like this:

 - common deployer identifies app and modules
 - (something) validates EAR
 - common deployer creates app MBean
 - for each RAR in EAR:
   - common deployer calls ConnectorContainer to validate a RAR, gets
     ObjectName for valid ones
   - common deployer gets connector MBean class from ConnectorContainer
   - common deployer creates Connector MBean w/class & ObjectName provided
   - common deployer sets properties on Connector MBean
   - common deployer tells Connector MBean to generate custom code
   - common deployer gets ClassSpace from Connector MBean
 - for each EJB JAR in EAR:
   - common deployer calls EJBContainer to validate a JAR, gets
     ObjectName for valid ones
   - common deployer gets EJB JAR MBean class from EJBContainer
   - common deployer creates EJB JAR MBean w/class & ObjectName provided
   - common deployer sets properties on EJB JAR MBean
   - common deployer tells EJB JAR MBean to generate custom code
   - common deployer gets ClassSpace from EJB JAR MBean
 - for each web app in EAR:
   - common deployer calls WebContainer to validate a web app, gets
     ObjectName for valid ones
   - common deployer gets web MBean class from WebContainer
   - common deployer creates web app MBean w/class & ObjectName provided
   - common deployer sets properties on web app MBean
   - common deployer tells web app MBean to generate custom code

Note that all the deployment plans and goals and tasks are managed by 
the common deployer -- when it says "creates web app MBean" and "sets 
properties on web app MBean" it really means "registers a task in the 
deployment plan to..."  So the WebContainer is doing web stuff not 
deployment plan stuff.

Then at start time, there are just a bunch of JSR-77 start() commands
executed, so the detailed startup logic is left to the module.

You seemed to be saying that there were web-specific steps that either the 
common deployer would do inappropriately or the web container wouldn't be 
given the opportunity to do -- would that still be the case?

Aaron

Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Jan Bartel <ja...@mortbay.com>]

Aaron,

> Jan (and Greg),
> 	This looks cool.
> 
> 	That said, I'd like to work on centralizing some of the deployment
> logic.  All the work of dealing with deployment plans and tasks is going
> to be fairly common across application module types, and we'll need to
> bring a lot of it together when we deploy an EAR anyway (arranging
> ClassLoaders and identifying context roots and so on).  
Firstly, there was a thread about deployment in general and web 
deployment in particular a few weeks (maybe a month? time flies) ago. 
The main particpants were Jeremy and myself. We digressed away from a 
discussion about xml deployment descriptors and got onto topics like the 
deployment model for web apps, web containers etc.

I agree there may be common code that can be extracted for the 
deployment of various j2ee artifacts such as ears and wars. This will 
come out as development continues and matures. However, there will 
inevitably be differences between deploying say, a war, and a rar. It 
seems to me almost as if you are arguing for one big happy generic 
"application" deployer rather than specific deployers. If so, then I 
don't agree with that approach.

> Also, the JSR-88
> model lets you distribute an application to one or more servers without
> starting it, and the MBeans need to created at distribute time so they can
> be invoked to start it
> 
> 	So I'd like to build most of that into the application deployer
> service, and then have the application deployer call out to the
> WebContainer, EJBContainer, etc. at a later stage, more like:
> 
> start(String contextRoot, ClassLoader parent, File warDir, (DD POJO));
> stop(...)
> restart(...)
> 
> 	Does that sound reasonable to you?  
Weeeeeell, yes ... and no. Probably mostly no, actually sorry. I think 
there are various issues here:

1. JSR88 deployment lifecycle vs geronimo hot deploy lifecycle
2. typed deployers
3. ear/war relationship

Starting with 1.:
the deployment model we have now only covers the geronimo hot deploy 
situation, where essentially we distribute and start a deployable in the 
one step. We now need to augment that model to cope with the more 
sophisticated JSR88 lifecycle. In other words, now we have (leaving 
aside implementation details like goals, plans etc for clarity) the 
following method on a Deployer:

   deploy (URL url)
   {
       //construct and configure JSR077 components

       //call JSR077 start() on them
   }

Which really consists of something like:

    distribute (URL url)
    {
       //construct and configure JSR077 components
    }

    start (URL url)
    {
       //call JSR077 start() on the components created in
       //the distribute step
    }

So, we should promote these two substeps into the geronimo deployment 
model to satisfy the JSR88 lifecycle model.

2. the central deployment mechanism should only be responsible for 
detecting things to be deployed, and arranging for distribute(), 
start(), undeploy() or whatever to be called on the appropriate 
deployer. Typed deployers are necessary because the things that are 
being deployed are different. Sure, they might go through a certain 
amount of common steps, and these can be abstracted for re-use within 
each deployer, but it does not follow that therefore there should only 
be one deployer for everything. For example, the web deployer, and only 
the web deployer, should be responsible for determining such things as 
the context path of a web application. This is very webby specific and 
the natural place for this is in a web module. The information that is 
used to determine that path can come from many sources: the name of the 
directory or war, a tag in an application DD, or an override in a 
geronimo-web DD, but the algorithm for choosing is specific to web 
deployments only.

The main reflection of this is that the deployment API should not
be webapp or service specific in any way.

3. wars can be deployed standalone, or bundled as part of an ear. In the 
latter case, then some of the deployment information for the war is 
contained in the deployment descriptor for the ear, and as you point 
out, the classloader hierarchy needs to be established. I think this 
should be handled as much as possible via the normal deployment mechanism.

To that end, I suggest we augment the signature of the deploy, 
distribute, undeploy etc methods with another parameter: 
DeploymentContext. This context can contain deployment descriptor POJOs 
or xml, or classloader objects or perhaps state information. Anything 
that defines the context in which the deployment is taking place.

Thus the ear/war deployment scenario I see is:

   + central deployment mechanism passes ear url off to the EarDeployer
     with a (probably) empty DeploymentContext object

   + EarDeployer detects an embedded war, so augments the
     DeploymentContext with appropriate contextual info and
     calls the central deployer mechanism with the url of the war and the
     DeploymentContext

   + the central deployer passes off the the war url and
     DeploymentContext to the war deployer

   + the war deployer does its *normal* thing, using any information
     provided in the DeploymentContext. eg. It is here that the logic is
     implemented to resolve the many ways a context path can be
     specified. The info for this logic is provided by the deployment
     mech, but the logic is in the webapp deployer.



Can you help me define what
> the WebContainer interface should look like for that?  For example:
> 
>  - Should we always unpack a WAR into a temporary dir before handing it
> over, or are you just as happy to get a packed WAR file?
The central deployer can choose to implement a policy of dectecting 
packed deployables and always unpacking them to a temporary directory. 
This policy should be configurable.

>  - When we go to undeploy or redeploy, can we identify an existing
> deployment by its context root or is there something better?
The deployer should only be identifying deployables by their url/uri.


>  - Do you need to be given the ObjectName for the web application?
I think it is up to the web deployment mechanism itself to work out the 
ObjectName for one of it's components. It should not be the concern of 
any other mechanism. Right now, the ObjectName of a WebApplication is 
created by the WebApplication itself, based on its context path. This is 
because WebApplications must be typed to the Container in which they 
reside, and the ObjectName contains this typing information.


>  - How can we manage it if two applications claiming the same context root
> are distributed (but not started)?  Presumably we need some way for a web
> app to "reserve" a context root before its started (we'd like the
> distribute to fail if the app couldn't be legitimately started afterward).
Two web deployer should accept distributions of webapps with the same 
context path. Whether or not that name conflicts with an already started 
webapp can only be determined at start time of the webapp.

cheers,
Jan
> 
> Thanks,
> 	Aaron
> 	
> 
> On Fri, 3 Oct 2003, Jan Bartel wrote:
> 
>>The "proper" (as opposed to the temporary Jetty integration) webapp 
>>deployment mechanism is available now in it's early stage. An 
>>integration with this mechanism for the Jetty web container is also 
>>available.
>>
>>To try it:
>>
>>1. stop geronimo
>>2. remove the target/geronimo-DEV/deploy/jetty/jetty-service.xml file 
>>and replace it with the modules/web/src/dev-jetty-service.xml file
>>3. start geronimo
>>
>>You should now be able to deploy packed wars and exploded wars via the 
>>normal geronimo deployment mechanism (ie dropping them in the 
>>target/geronimo-DEV/deploy directory). At the moment, wars containing 
>>uncompiled JSPs won't work, as an enhancement to Jetty is needed to 
>>extract a suitable JSP compile classpath from the geronimo classloader 
>>hierarchy before Jasper will be able to compile on-the-fly. Greg has 
>>this patch nearly ready. One caveat - I haven't had a chance to do much 
>>testing on this yet beyond dropping the geronimo-web-console.war into 
>>the deploy directory, so expect some surprises. Also be aware that there 
>>is no JNDI ENC support from the web deployer yet as there isn't (AFAIK) 
>>any datasources, ejbs etc yet within geronimo to put into such an ENC.
>>
>>One valuable feature of the geronimo web deployment mechanism is that 
>>web layer objects such as listeners (aka connectors) and access logs are 
>>first class Geronimo services. This means that the configuration for 
>>them can be expressed in standard Geronimo mbean config syntax, rather 
>>than needing extra web-container specific config files. Here is the 
>>dev-jetty-service.xml file which contains all you need to get the Jetty 
>>container deployed and serving webapps on port 8088:
>>
>>
>><components>
>>   <!-- ============================================================ -->
>>   <!-- Set up the Jetty-specific jars                               -->
>>   <!-- ============================================================ -->
>>   <class-space name="geronimo.system:role=ClassSpace,name=Jetty">
>>     <codebase url="file:lib/">
>>       <archive name="*"/>
>>     </codebase>
>>     <codebase url="file:../../lib/">
>>       <archive name="geronimo-core-DEV.jar"/>
>>       <archive name="geronimo-common-DEV.jar"/>
>>     </codebase>
>>   </class-space>
>>
>>   <!-- ============================================================ -->
>>   <!-- Set up a Jetty container                                     -->
>>   <!-- ============================================================ -->
>>   <mbean code="org.apache.geronimo.web.jetty.JettyWebContainer"
>>          name="jetty:role=WebContainer">
>>    <attribute type="java.net.URI"
>>               name="DefaultWebXmlURI">file:web-defaults.xml</attribute>
>>   </mbean>
>>
>>   <!-- ============================================================ -->
>>   <!-- Set up a connector to listen for http requests               -->
>>   <!-- ============================================================ -->
>>   <mbean code="org.apache.geronimo.web.jetty.JettyWebConnector"
>>          name="jetty:role=WebConnector, port=8088">
>>     <attribute name="Port">8088</attribute>
>>     <depends name="jetty:role=WebContainer"/>
>>   </mbean>
>></components>
>>
>>
>>On my list for the very near future is:
>>+ support for undeploy
>>+ support for webdefaults
>>+ support for JSR88 required data for webapps
>>+ JNDI ENC
>>+ parsing of web.xml and geronimo-web.xml deployment descriptors
>>+ support for a geronimo web access log service
>>+ testing, testing, testing
>>
>>The longer term:
>>+ more testing :-)
>>+ support for web apps deployed inside an ear
>>+ support for redeploy
>>+ support for registering context names with a listener which
>>   must be deployed on the container before the listener will
>>   accept connections
>>+ support for simultaneous deployment of different web containers (eg
>>   Jetty and Tomcat in parallel)
>>
>>
>>I will try to update all this on the Geronimo wiki in the next few days. 
>>Just thought as the subject came up, I'd give everyone an update on what 
>>is happening in web-app deployment land.
>>
>>cheers
>>Jan
>>

Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)

[Aaron Mulder <am...@alumni.princeton.edu>]

Jan (and Greg),
	This looks cool.

	That said, I'd like to work on centralizing some of the deployment
logic.  All the work of dealing with deployment plans and tasks is going
to be fairly common across application module types, and we'll need to
bring a lot of it together when we deploy an EAR anyway (arranging
ClassLoaders and identifying context roots and so on).  Also, the JSR-88
model lets you distribute an application to one or more servers without
starting it, and the MBeans need to created at distribute time so they can
be invoked to start it.

	So I'd like to build most of that into the application deployer
service, and then have the application deployer call out to the
WebContainer, EJBContainer, etc. at a later stage, more like:

start(String contextRoot, ClassLoader parent, File warDir, (DD POJO));
stop(...)
restart(...)

	Does that sound reasonable to you?  Can you help me define what 
the WebContainer interface should look like for that?  For example:

 - Should we always unpack a WAR into a temporary dir before handing it
over, or are you just as happy to get a packed WAR file?

 - When we go to undeploy or redeploy, can we identify an existing
deployment by its context root or is there something better?

 - Do you need to be given the ObjectName for the web application?

 - How can we manage it if two applications claiming the same context root
are distributed (but not started)?  Presumably we need some way for a web
app to "reserve" a context root before its started (we'd like the
distribute to fail if the app couldn't be legitimately started afterward).

Thanks,
	Aaron
	

On Fri, 3 Oct 2003, Jan Bartel wrote:
> The "proper" (as opposed to the temporary Jetty integration) webapp 
> deployment mechanism is available now in it's early stage. An 
> integration with this mechanism for the Jetty web container is also 
> available.
> 
> To try it:
> 
> 1. stop geronimo
> 2. remove the target/geronimo-DEV/deploy/jetty/jetty-service.xml file 
> and replace it with the modules/web/src/dev-jetty-service.xml file
> 3. start geronimo
> 
> You should now be able to deploy packed wars and exploded wars via the 
> normal geronimo deployment mechanism (ie dropping them in the 
> target/geronimo-DEV/deploy directory). At the moment, wars containing 
> uncompiled JSPs won't work, as an enhancement to Jetty is needed to 
> extract a suitable JSP compile classpath from the geronimo classloader 
> hierarchy before Jasper will be able to compile on-the-fly. Greg has 
> this patch nearly ready. One caveat - I haven't had a chance to do much 
> testing on this yet beyond dropping the geronimo-web-console.war into 
> the deploy directory, so expect some surprises. Also be aware that there 
> is no JNDI ENC support from the web deployer yet as there isn't (AFAIK) 
> any datasources, ejbs etc yet within geronimo to put into such an ENC.
> 
> One valuable feature of the geronimo web deployment mechanism is that 
> web layer objects such as listeners (aka connectors) and access logs are 
> first class Geronimo services. This means that the configuration for 
> them can be expressed in standard Geronimo mbean config syntax, rather 
> than needing extra web-container specific config files. Here is the 
> dev-jetty-service.xml file which contains all you need to get the Jetty 
> container deployed and serving webapps on port 8088:
> 
> 
> <components>
>    <!-- ============================================================ -->
>    <!-- Set up the Jetty-specific jars                               -->
>    <!-- ============================================================ -->
>    <class-space name="geronimo.system:role=ClassSpace,name=Jetty">
>      <codebase url="file:lib/">
>        <archive name="*"/>
>      </codebase>
>      <codebase url="file:../../lib/">
>        <archive name="geronimo-core-DEV.jar"/>
>        <archive name="geronimo-common-DEV.jar"/>
>      </codebase>
>    </class-space>
> 
>    <!-- ============================================================ -->
>    <!-- Set up a Jetty container                                     -->
>    <!-- ============================================================ -->
>    <mbean code="org.apache.geronimo.web.jetty.JettyWebContainer"
>           name="jetty:role=WebContainer">
>     <attribute type="java.net.URI"
>                name="DefaultWebXmlURI">file:web-defaults.xml</attribute>
>    </mbean>
> 
>    <!-- ============================================================ -->
>    <!-- Set up a connector to listen for http requests               -->
>    <!-- ============================================================ -->
>    <mbean code="org.apache.geronimo.web.jetty.JettyWebConnector"
>           name="jetty:role=WebConnector, port=8088">
>      <attribute name="Port">8088</attribute>
>      <depends name="jetty:role=WebContainer"/>
>    </mbean>
> </components>
> 
> 
> On my list for the very near future is:
> + support for undeploy
> + support for webdefaults
> + support for JSR88 required data for webapps
> + JNDI ENC
> + parsing of web.xml and geronimo-web.xml deployment descriptors
> + support for a geronimo web access log service
> + testing, testing, testing
> 
> The longer term:
> + more testing :-)
> + support for web apps deployed inside an ear
> + support for redeploy
> + support for registering context names with a listener which
>    must be deployed on the container before the listener will
>    accept connections
> + support for simultaneous deployment of different web containers (eg
>    Jetty and Tomcat in parallel)
> 
> 
> I will try to update all this on the Geronimo wiki in the next few days. 
> Just thought as the subject came up, I'd give everyone an update on what 
> is happening in web-app deployment land.
> 
> cheers
> Jan
>