geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: The autodeploy feature in Geronimo
Date Mon, 24 Oct 2005 17:18:15 GMT

Joe Bohn wrote:
> I agree with the notion that any "hot deploy" directory we deliver 
> should be only for deploy/redeploy.   However, I don't think that makes 
> it necessary to remove the items once they were deployed.  I agree with 
> Geir that we should keep things there so that you can verify what is 
> really active at any given time.
> I have a somewhat different view on this (perhaps entirely wrong) but 
> I'd like to toss it out there.
> How about if we provide a "hot deploy" location that acts as an 
> "addition/over-ride" location much the same as adding a library earlier 
> in a path.  I tend to think of this "hot deploy" activity as a developer 
> activity and so I think most folks running a production server would 
> follow the traditional deploy, undeploy, redeploy mechanics.  Hot-deploy 
> would most likely be used exclusively in development or to "patch" a 
> critical problem with a temporary fix.
> If this idea has any merit then I would propose the following:
> - The hot deploy location would be used as a the initial place to look 
> for any application or application element prior to looking in the 
> config-store.   Therefore, it could be used to over-ride items from a 
> previously deployed application.


> - New applications added to the hot-deploy location would not be fully 
> "deployed" in the sense of being added to the config-store.  Rather, 
> they would be deployed to a temporary location (possibly somewhere under 
> the same hot-deploy location).  That will keep the two deployment types 
> and locations distinct.

IMHO this could get really ugly.  I think we need a single location.  If 
we have a hot-deploy directory, then it should be there to make is easy 
to auto deploy instead of running a script.

> - Applications which only existed in the hot deploy location and were 
> removed would be "undeployed" from the temporary location (but not from 
> the config-store since a hot-deploy item is never included in the 
> config-store).  This would then result in the application being 
> completely removed from the system if it was never fully deployed to the 
> config-store or the original, deployed application would then once again 
> become the "used" application.

This is where we run into problems.  We now have 2 deploy areas with 
files that may or may not be representative of the same application. 
This is why I believe that if we do this...the jar/war/ear/rar (or what 
have you) will disappear - meaning Geronimo deployed it - or had its way 
with it.  I am going to agree with David Jencks that this should be a 
very unstandard way of doing things due to the JSR issues.  I think 
having 2 deployment areas will cause us a tremendous amount of problems 
in ensuring both areas represent the same area.  This is why I am saying 
it should be for deploy/redploy only and "poof" it is gone.  This should 
be a development-only tool, and I would like that if we do this, that 
its something that needs to be enabled and is not available in the 
default configuration.

> - There would be no capability to really undeploy an application that 
> has been deployed to the config-store ...only the ability to over-ride 
> it or stop over-riding it.

Yes...this was my thinking.

> Thoughts?
> Joe
>>> What does tomcat allow?
>>> Sachin
>>>>>> Jacek

View raw message