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