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 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.
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.
thanks
david jencks
