Simplifying the deployment model

[David Oren <da...@gmail.com>]

I'm currently looking into a way of simplifying the Geronimo deployment 
process and making it more friendly to a web-developer used to working with 
Tomcat or Apache.

The way many developers work with Tomcat is by working directly in Tomcat's 
webapps folder -- it's easy, it's quick, and in many cases it's good enough. 
If the application needs to be moved to another server, you copy the tree 
structure to the new server, and you're done.

Geronimo, on the other hand, follows the J2EE deployment model: applications 
have to be packaged in special files, and deployed to the server. This 
breaks the more intuitive Tomcat and Apache development cycle. Of course, 
once an application is deployed, its files can be modified in Geronimo's 
config-store -- but while finding the correct directory there is easy, it is 
not trivial. In addition, you still end up with having two versions of the 
application, one in the directory where you originally put it, and another 
in the config-store.

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.

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

Thanks,

David Oren

Re: Simplifying the deployment model

[Miguel A Paraz <mp...@gmail.com>]

On 9/16/05, David Oren <da...@gmail.com> 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.

I believe it's better that all the files Geronimo accesses remain
inside its directory hierarchy. As a newbie I used to edit files
inside Tomcat directories, but then I realized it's a bad idea.

To follow Tomcat deployment: how about a hot deploy directory where
you could copy your WARs (and EARs later)

Re: Simplifying the deployment model

[Jeremy Boynes <jb...@apache.org>]

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