geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: Simplifying the deployment model
Date Fri, 16 Sep 2005 06:20:01 GMT
David Oren wrote:
> What I'd like to suggest is adding the ability to "deploy" directories -- 
> that is, instead of having to package an application in a war or ear file 
> and then deploying that file, the deployer will be given the full path where 
> the application is located. The application will be added to Geronimo, will 
> not be copied to the config-store directory (which will contain only the 
> .ser files) and instead, will be run from its current directory.

Sachin and I discussed something like this at OSCON, the challenge being 
how to simplify this kind of setup with applications that were more 
complex than straight JSP applications. For example, when the JSP used 
information from beans that were populated by EJB calls.

The web containers (both Jetty and Tomcat) allow you to specify where 
the content root is located. During normal deployment we set that to be 
the location inside the config where we put the war's content (the 
deployer knows nothing about the internal layout of the config store) 
but there is no reason why this needs to be.

The rough idea we discussed was to allow applications to be deployed as 
normal (so all the JDBC and EJB references get resolved as expected) but 
to change the way the content roots were defined to refer back to the 
original source tree. That way web content (primarily JSPs and static 
content) could be modified easily and the result of the change seen 
without needing to redeploy the application. The easiest way to 
implement this would be with an element in the web deployment plan that 
specified where the content root was; that would allow for applications 
(e.g. portal apps) containing multiple wars.

Combined with the ability to restart the application (triggering for 
example servlet lifecycle events that would cause frameworks like struts 
to reload their configuration data) this seemed to fit the bill.

Of course, we then got distracted and haven't started implementing yet :-)

> I have a very early proof of concept that enables this feature for web 
> applications, and I can post it if there's any interest.

I think there would be a lot of interest. Best way to post would be to 
open a JIRA and attach the jar/patch to it. Please make sure the 
"contribute to Apache" flag is set.

> I'd be happy to hear any comments on this idea, and also suggestions on what 
> you think will be the cleanest way to go about implementing this.

Look forward to seeing it.

View raw message