geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: The autodeploy feature in Geronimo
Date Mon, 24 Oct 2005 17:39:42 GMT

On Oct 24, 2005, at 10:05 AM, Joe Bohn wrote:

> Jeff Genender wrote:
>> Sachin Patel wrote:
>>> Wouldn't it be more confusing to the user if their file got removed 
>>> after it got deployed? I feel the point of a "live" directory is for 
>>> the runtime to be able to react to any changes to it, including 
>>> deletions. Both Jboss and Websphere's hot deploy capability allow 
>>> deletions.
>> I would like to get more input on this.  I really believe a hot 
>> deploy directory should be just for deploy/redeploy.  There 
>> was some great discussion in the past on this (check the lists). But 
>> I am open to this.  The problems we will run into this whole idea is 
>> managing the plans and ensuring the dropped wars/jars/ears/rars/etc 
>> are the same in the config store.  Then, also what about exploded 
>> libs?
>> I wouldn't necessarily say the because WS and JBoss have it, means 
>> its the right way. How is BEA doing it?  We should think about this 
>> all the way through before going down a path.
> 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.

Hot deploy has got to be a very secondary method for unsophisticated 
developers who don't care much about tracking what state there server 
is in.  Since it is fundamentally inconsistent with the required jsr-88 
stuff we should not break our architecture to support a bad although 
popular idea.
> 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.

I have no idea how this could possibly work.  Could you explain?  Say 
you have an application deployed using jsr-88 or the maven plugin as 
part of your development process.  How would you use the hot deploy 
directory to undeploy the already deployed app and deploy the "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.

  I can't see the use of this, or how to make it work, and I think it 
would cause complete confusion.
> - 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.

We could have another config-store for these, but I really don't see 
what the point would be.
> - 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.
> - 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.

If we had 2 config stores, with the one used by hot deploy preceding 
the normal one in the configuration manager's list of config stores 
(although I don't think its ordered at the moment) then when you  
restarted the server you'd get the hot-deployed one.   But stopping and 
removing the original app from the config store is a much smaller 
operation than restarting the  server.  Why would you force someone to 
restart the server rather than just administering configurations?

I really don't understand where you are trying to go with this idea.

david jencks

View raw message