Bug 33572 - webapp not reload after META-INF/context.xml change
Summary: webapp not reload after META-INF/context.xml change
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.5.7
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-14 23:08 UTC by Trevor Baker
Modified: 2005-02-16 16:48 UTC (History)
0 users



Attachments
test webapp for the prob (1.06 KB, application/octet-stream)
2005-02-14 23:09 UTC, Trevor Baker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Trevor Baker 2005-02-14 23:08:06 UTC
I have an unpacked webapp (named test) and if I change the web.xml for it, the
webapp gets reloaded. However if I change the META-INF/context.xml for it, it
doesn't get reloaded. It's a WatchedResource too like web.xml. All I'm doing is
changing a context-param value in context.xml (as a trivial example to explain
my issue).

When I change context.xml, I get this in the log:
Feb 13, 2005 6:11:39 PM org.apache.catalina.startup.HostConfig checkResources
INFO: Reloading context [/test]

So it looks like it should be reloaded, but my param doesn't.

In:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/context.html

There is:
<snip>
WatchedResource - The auto deployer will monitor the specified static resource
of the web application for updates, and will reload the web application if is is
updated. The content of this element must be a string.
</snip>

So I'm not dreaming.

I've also tried restaring the webapp with the manager webapp and still no change
to the param.

I'm attaching a webapp that can be dropped into the default tomcat 5.5.7.
Comment 1 Trevor Baker 2005-02-14 23:09:02 UTC
Created attachment 14282 [details]
test webapp for the prob

sample webapp of issue
Comment 2 Remy Maucherat 2005-02-14 23:43:18 UTC
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.
Comment 3 Trevor Baker 2005-02-15 06:32:55 UTC
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...
Comment 4 Remy Maucherat 2005-02-15 17:22:25 UTC
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.
Comment 5 Trevor Baker 2005-02-16 21:40:22 UTC
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.
Comment 6 Trevor Baker 2005-02-16 22:05:58 UTC
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?
Comment 7 Remy Maucherat 2005-02-16 22:16:55 UTC
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).
Comment 8 Trevor Baker 2005-02-17 01:28:34 UTC
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.
Comment 9 Remy Maucherat 2005-02-17 01:48:01 UTC
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.