Summary: | webapp not reload after META-INF/context.xml change | ||
---|---|---|---|
Product: | Tomcat 5 | Reporter: | Trevor Baker <amoebaworks> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P3 | ||
Version: | 5.5.7 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Attachments: | test webapp for the prob |
Description
Trevor Baker
2005-02-14 23:08:06 UTC
Created attachment 14282 [details]
test webapp for the prob
sample webapp of issue
You are confusing issues. The issue is not that the application is not reloaded (it obviously is), but just that a reload will not reload the context.xml information. Since this information is actually used to create and initialize the context, the web application needs to be fully redeployed (which is not done at the moment) for the information in META-INF/context.xml to be reread. I will see if it is possible to do. Otherwise, it will be a WONTFIX. Okay I can see that now. I assumed that even the context.xml values would be reloaded when a webapp is reloaded. So for now, to get these values to reload I have to do an undeploy (which deletes the dir) and then a deploy in the manager webapp. Bit of a pain from a usability point of view. If the decision is a WONTFIX, then please make a change in the docs to eliminate such assumptions for future users. wow...I'm actually admiting to reading docs...what's next... I tweaked handling of the context.xml files, which are now no longer regular watched resources, but will trigger a full redeployment (but without deleting everything, obviously). My changes seem to work, but there are quite a number of different cases, so it is tricky. Please test it. The changing of META-INF/context.xml seems to work for me too. I think I've noticed a side-effect since this "feature" is not in the 5.5.7 release. All of this is using Catalina/localhost/test.xml instead of /META-INF/context.xml for the /test context. start up tomcat, with Catalina/localhost/test.xml and /test webapp in webapps dir. in 5.5.7: 1) change the test.xml 2) webapp doesn't get reloaded with new values. Nothing new here. in the cvs head w/context reload: 1) change test.xml. 2) /test webapp dir gets deleted. In the manager, /test is listed as not running but not undeployed 3) Try to start, but get FAIL - Application at context path /test could not be started (obviously because the dir deleted) 4) add /test webapp back into webapps dir. start /test context with manager 5) goto #1 Again would be nice to change the values of Catalina/localhost/test.xml and reload the webapp properly too. just want to make an additional note... for Catalina/localhost/test.xml: if /test is expanded from test.war in the webapps dir, then a change to test.xml will: 1) delete /test dir 2) reload context 3) expand test.war to /test dir 4) everything is okay. But does /test dir need to be deleted in this case? Ok. So the first one is now fixed in CVS, and the second one is as expected (my idea is that you can change things like unpackWAR on the Context element, so the expanded folder is removed). The first is good. As for the second (expanded WAR being deleted). It doesn't delete the expanded dir when the conf/.../test.xml's values change...which is good. Your last comment is a little confusing...is deleting the expanded WAR something you wanted? in general? or just when the unpackWAR="false"? From your comment I decided to play around a bit more... test #1: 1) start up tomcat with nothing for /test (dir, context, etc...). 2) drop /test into webapp dir. Gets deployed with default context. 3) drop test.xml into conf/.../. Still uses default context. 4) reload /test from manager. Still uses default context. It should redeploy using test.xml when I drop it into conf/.../ The opposite is correct(?) If a deployed webapp (/test using conf/.../test.xml) has conf/.../test.xml removed, then the webapp is redeployed using the default context. test #2: I have deployed: /test using conf/.../test.xml. If I remove /test dir then test.xml is removed too. Is that planned behaviour...a complete undeploy? test #3: I have deployed: test.war with expanded /test dir using conf/.../test.xml. If I remove /test dir then test.xml is removed too. Then /test dir is recreated from test.war using the default context. Is that planned behaviour...an undeploy followed by complete new deploy? Changing context values redeploy with nothing getting deleted (as noted above). test #4: I have deployed: test.war with expanded /test dir using conf/.../test.xml. I change test.xml to unpackWAR="false", and it's still accessing files from /test and not test.war. If I delete /test dir I get test #3 obviously. Changing context values redeploy with nothing getting deleted (just still uses expanded dir). Is that planned behaviour? test #5: I have deployed: test.war using conf/.../test.xml with unpackWAR="false". What happens if I delete test.war? I have a Windoze box that doesn't allow me to delete the war, so I can't test this but I'm assuming that test.xml is deleted too. right? Changing context values redeploy with nothing getting deleted. If you are looking for software that reads your mind, then this is cool, but I am not going to do it. I consider the current behavior, as fixed (the behavior originally described in the bug report is a bug), good enough, and fairly consistent. If you think it is perfectible, then feel free to submit patches. |