geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)
Date Mon, 06 Oct 2003 07:54:07 GMT

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


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)

View raw message