I've made one final attempt to clarify my proposal. If it's still
hair-brained then I'll let it fade into the dev archives ... :-)
David Jencks wrote:
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 agree (as I mentioned a little lower in my original post). The
primary goal here should be to provide a quick means to update or change
items during development. It could also be used to provide quick
patches for problems in production but this is not essential. However,
it should not replace the general deployment mechanisms. This is
exactly why I think we should keep the items from hot-deploy distinct
from config-store and not allow those things to corrupt the
config-store. If we don't keep these distinct than an attempt to make a
change and back it out without permanently affecting the installed
application would impossible.
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"?
I did preface my original post with the disclaimer that this view could
be "entirely wrong" :-). This may be too complicated and not feasible
... but before we dismiss it I'd like to ensure that the concept is
understood.
Perhaps part of the problem here is terminology so let's use these terms:
- jsr88-deploy/deployment - the current deploy capability that populates
config-store.
- config-store - the repository for jsr88-deployed applications
- hot-deploy/deployment - the alternative deployment capability that I'm
suggesting that could populate the hot-config-store.
- hot-config-store - the repository for hot-deployed applications
The actual processing during deployment could be consistent for both the
jsr88-deploy and the hot-deploy assuming that the deployment process
itself was updated to reference the hot-config-store prior to the
config-store.
To answer your question about undeploy using these terms .... you would
never undeploy a jsr88-deployed item using hot-deploy. If you removed
an EAR/WAR/JAR/RAR... from the hot-deploy location then the
corresponding items would be removed from the hot-config-store. To
remove an item from the config-store would require a jsr88-deployment
undeploy. Since config-store is the "official" deployment location then
any jsr88-undeploy should also remove any corresponding elements from
the hot-config-store but not vice-versa.
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.
I don't think this is arbitrarily complex.
Given the following:
- lib1 contains MyApplClass.class
- lib2 contains MyApplClass.class
- path = .... lib1;lib2....
Is it confusing that MyApplClass.class from lib1 will be used when
searching path? If you remove MyApplClass from lib1 would you not
expect that MyApplClass from lib2 would be used? This is all that I'm
proposing for hot deploy.
The only difference with this proposal is that it must deal with
complete applications which must be deployed as a unit in addition to
individual components. Hence the resultant "path" when locating
classes, applications, etc... would be:
hot-deploy-location;hot-config-store;config-store
where:
- hot-deploy-location is for individual file/component over-rides
- hot-config-store is for deployed application over-rides (EAR/WAR/JAR....)
- config-store - same as now ...
- 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 certainly wasn't proposing that we replace one config-store with
another and hence require a server restart. If the architecture is such
that it's technically impossible to provide this file-level and
application-level override without a server restart then we should just
drop this idea for now.
I really don't understand where you are trying to go with this idea.
I hope I clarified that above ... I'm more than willing to let this die
if I can't get others to see the value or if it's not practical.
thanks
david jencks
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
