Remy Maucherat wrote:
Josh Rehman wrote:
This TC5 "feature" concerns me so much I've written up a bug. Please feel free to comment on it and/or vote for it.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26676
It's closed now ;)
Well, that's a quick response, although not the one I had hoped for.
This is obviously a problem, and deserves more attention than a quick closure. If 3 people here have the problem, then at least 100 people out there have the problem, and haven't bothered to say anything about it. This is especially true for those coming from 4.x where this did not happen. There is certainly nothing in the documentation warning against Context modifications in server.xml.
Indeed, even if there was that would be a bad idea. Apache works that way, and people are used to it. Why not just have Tomcat reload server.xml if you want to support context parm changes without a restart? That would be a great feature! If the concern is reloading in the middle of an incomplete edit, there are ways around that. And besides, that would seem to be a problem no matter what. Come to think of it, I don't see why you can't reload server.xml.
Basically, it would be the same as restarting the whole server (with the gain of the VM startup time). So it's not useful.
You write in the bug:
You are not supposed to add Context declarations to server.xml, because the contexts then become impossile to manage. This works as designed, but it is obviously different from Tomcat 4.1.x.
How exactly do Contexts become impossible to manage? They seemed to work fine under all previous versions of Tomcat.
Ex: - you want the container to undeploy dynamically a context - you want to update stuff in your context element dynamically
Saving the whole server.xml for these cases is error prone, and basically a big hack.
What I recommend with TC 5 is put your context declarations in /META-INF/context.xml, and use the manager to manage your webapps. If using external contexts, then it's the similar: either use the manager webapp or drop your context file in the right subdir of "conf" (and use the manager to undeploy).
-- xxxxxxxxxxxxxxxxxxxxxxxxx Rémy Maucherat Developer & Consultant JBoss Group (Europe) SàRL xxxxxxxxxxxxxxxxxxxxxxxxx
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
