Community
Participate
Working Groups
Created attachment 191205 [details] WAB With the attached WAB in pickup and the attached configuration in: config/Catalina/localhost the request dumper valve runs when localhost:8080/samplewab is invoked. If the WAB is undeployed and redeployed, or simply refreshed, the request dumper valve no longer runs. The request dumper valve may be seen in action by tailing serviceability/logs/log.log.
Created attachment 191206 [details] context configuration
If Virgo Tomcat server is restarted, the request dumper valve then starts running again when the sample WAB is driven.
The problem is a bit different. Here is what happens: When the application is undeployed, the following method is invoked: org.eclipse.gemini.web.tomcat.internal.loading.BundleWebappClassLoader.clearReferences() In this method we try to: - Unregister JDBC drivers loaded by the web application's classloader - Clear the IntrospectionUtils cache - Clear the classloader reference in the VM's bean introspector - Clear the classloader reference in common-logging Actually the last one invokes: org.apache.juli.logging.LogFactory.release(this); This will invoke java.util.logging.LogManager to reset Loggers and to close all Loggers' handlers. In Virgo we use the default java.util.logging.LogManager so when the web application is undeployed all Loggers are reset and their handlers are closed. When the application is deployed again and we make a request, RequestDumperValve tries to log, but there are no handlers that can process this invocation. In pure Tomcat there is an extension of java.util.logging.LogManager called org.apache.juli.ClassLoaderLogManager It is made in a way to reset only org.apache.juli.ClassLoaderLogManager ... 327 private void resetLoggers(ClassLoaderLogInfo clLogInfo) { 328 // This differs from LogManager#resetLogger() in that we close not all 329 // handlers of all loggers, but only those that are present in our 330 // ClassLoaderLogInfo#handlers list. That is because our #addLogger(..) 331 // method can use handlers from the parent class loaders, and closing 332 // handlers that the current class loader does not own would be not 333 // good. ... So I tried the following: - Copied com.springsource.org.apache.juli.extras.springsource-6.0.29.S2-r1559.jar in <Virgo-Home-Dir>/lib - Added the following to the <Virgo-Home-Dir>/bin/dmk.bat: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager Now I can see the RequestDumperValve logs always i.e. there is no problems any more. But with this LogManager I can see logs only in the console and not in the log files :( So there two possible solutions: - to make our java.util.logging.LogManager extension - to remove org.apache.juli.logging.LogFactory.release(this) from BundleWebappClassLoader.clearReferences()
I am nervous about removing the release call from clearReferences as the purpose was to avoid a memory leak and the memory leak would probably return.
(In reply to comment #4) > I am nervous about removing the release call from clearReferences as the > purpose was to avoid a memory leak and the memory leak would probably return. Yes I agree that removing release call from clearReferences method is not a good idea. So we are going into direction to extend java.util.logging.LogManager?
Yes, that's seems like the best direction to explore.
Deferring to next release.
Since 3.5.0 has shipped, targeting 3.6.0. If this bug is more urgent, please target 3.5.1 and provide a fix.
Missed 3.6.0, so targetting 3.7.0.
Missed 3.7.0, so targetting 3.8.0.
