geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)
Date Fri, 03 Oct 2003 12:47:22 GMT
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
> 


Mime
View raw message