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.
Yes....agreed.
- 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
