Darryl L. Miles a écrit : > David Delbecq wrote: > >> I experienced a strange behaviour of tomcat a few minutes ago. Container >> is configured to do webapp auto reloading when classes changes. I >> updated a few WEB-INF/classes/*.properties. Tomcat decided it's time to >> reload the webapp because classes did change. However, it killed it's >> own webapp loader Thread using a ThreadDeath. As a result, the webapp is >> not accessible anymore. I suppose it's a bug from the webapp reloader, >> but before submission to bug tracker, i'd appreciate comments. >> >> The result of this problem is >> 1) webapp does not exist anymore (404 while trying to access it) >> 2) webapp is marqued in manager as not started, but trying to start it >> result in an 'already started' error >> 3) you must either restart tomcat, either undeploy/redploy the webapp to >> get it back working >> > > I have also experienced behavior similar to what you describe. I have > been able to categorize a few distinct variants. First of all, can > you reliably re-create the variant you have just witnessed ?
Not reliably. I was able to reproduce it a few times after the error occured, but it all seems to be somehow random. Only common step is, it happens during webapp redeploy, like a container class is using a webapp class and so keeps it. Note it might be related to another problem i have in my environnment. If i switch from j2sdk1.4.2_05 to j2sdk1.4.2_11, tomcat does not start anymore, invoking a class circularity exception in logger system. I have no clue on what causes this, but if tomcat tries to use the webapp classloader for it's logging purpose, that might explain. I maybe have a problem in loggers configuration i need to investigate (considering 4 different logging mecanisms are interacting, that could be fun :p ) > > For some reason that I don't understand the container chooses to use a > logger instance that is loaded through the WebappClassLoader for its > own purposes. Maybe this is mandated in specifications, maybe this is > so that a web-app has some control internally over context related > logging events the container generates. But in my own testing if the > container sticks with its own logger instance (not loaded via > WebappClassLoader) then it remain inert to (mis)configuration effects > the web-app chooses to make. i don't think it's in specs. Moreover i never wrote any similar rule in my webapp config. There is no reason tomcat should use my webapp classes for logging purpose... > > I believe the variant you witnessed can be reduced into a simple > situation where the web-application might reconfigure its logger > instance (which it rightfully believes its own to do so) in such a way > to cause problems to the container when it tries to use it later. > This problem shows up in a future container logging event. I believe it's more the container using a class that don't exist anymore as webapp is undeployed. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
