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 that..to 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.
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.
- 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.
Thoughts?
Joe
What does tomcat allow?
Sachin
Jacek
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
