geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <>
Subject Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)
Date Sat, 04 Oct 2003 03:57:37 GMT

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


View raw message