On Fri, 3 Oct 2003, n. alex rupp wrote:
> Q&A from the wiki page asked this question:
>
> "Question: What happens if you place an application module in the
> auto-deploy directory, so it is deployed, and then you go in via JSR-88 and
> undeploy it? Presumably, it must be removed from the auto-deploy directory,
> so it won't get auto-redeployed next time the scanner wakes up. "
>
> I'm curious whether we could simply move the application module to an
> "undeploy" directory, which would allow people to work on unpacked archives
> and undeploy without deleting their work-in-progress.
That makes sense to me, but then the next question on that page is
something along the lines of "what if you've set a read-only URL (WebDAV
or a network filesystem or something) to be the auto-deploy directory?"
In that case, we couldn't move the archive out of the deploy directory.
I wonder if instead we shouldn't have some way to indicate to the scanner
or the deployment controller that a certain xAR or dir has been undeployed
and should be skipped in the future. But then this ties back to the issue
in my other message, if you restart the server, should that undeployed app
still be undeployed? In which case we need some sort of config file to
say which apps are in which state.
Also, in addition to "undeployment", there can be a "stopped"
application, which is not running but still "distributed" to the server.
If you "stop" an application in the deploy directory, it should probably
stay there but just be in a non-running state, so you can then "start" it
again. Perhaps we're OK to delete apps from the deploy directory if they
are undeployed, so long as we keep them in place when they're stopped, but
of course this would still leave us with the read-only deploy dir issue.
Aaron
