Thanks, Mark.
1. I just tried to reproduce the issue on my pc. And I couldn't, which
is a good thing. I will try it again later on the server, with which I
had the issue yesterday.
2. OK
3. Can live with that
Mark Thomas wrote:
Igor Mukhin wrote:
1.
I have looked at the new documentation and the new code in
org.apache.catalina.startup.HostConfig.java. And my first question is:
what is reason behind redeploying the application after detecting an
update of /conf/.../<ctxpath>.xml? (6.0.18 restarts the application in
this case)
Just think about it: You have an tomcat production server with 200
applications. All application were deployed statically and they (and
you) have no .war files. You can't restart the tomcat. But you need to
update the database resource parameter in /conf/.../<ctxpath>.xml of an
application promtly. You edit the file, save it. In a minute a customer
calls you on the phone and tells the application is not accessible. You
look into appBase, but the app is not there. Tomcat has deleted it (in a
try to redeply, but there is not .war file to deploy) ?!?! Where are my
files?!?!?
That sounds like a regression and a nasty one at that. Touching the context.xml
file should trigger a reload not a redploy and then only if autoDeploy="true"
for the host. I'm not in a position to test this right now. Are you sure the
context.xml file was only updated?
The only way an undeploy should be triggered is if the context.xml file is
deleted (and autoDeploy="true"). This has always been the case.
2.
If I deliver a patch that makes the behavoir after updating a
/conf/.../<ctxpath>.xml configurable, could it be included in the next
version?
Something like <Context ...
onDetectContextXmlUpdate="redeploy|reload|ignore"> where "redeploy" is
default to keep new behavior
No need. ignore is achieved by setting autoDeploy="false". undeploy is triggered
if the context file is deleted and reload is triggered if the context file is
updated. There is no way to trigger a (re)dploy. This wouldn't make much sense
as a deployment needs a source and there is no obvious way of specifying one.
3.
If I deliver a patch that optionally turns off copying
/META-INF/context.xml to /conf/.../<ctxpath>.xml, could it be included
in the next version?
Something like <Host ... copyFirstApplicationContextXml="true|false">,
where "true" is default to keep new behavior
Unlikely. The extraction of the context.xml file was a 6.0.x design decision. If
the patch came with a convincing argument for the additional complexity then it
would certainly get into 7.0.x and might get into 6.0.x and 5.5.x. That said,
the tricky bit would be the convincing argument. I'd suggest trying to make your
case before you spend time on the patch.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
