I'm not sure if this is a known bug, a misconfiguration on my part or a "feature". I use java.util.logging. I want to be able to change the Logger levels remotely via JMX (JConsole). As it seems one cannot use JULI and use the LoggingMXBean successfully at the same time. One can either set the Logger level remotely but not the Handler level (without JULI) or one can set the Handler level but not the Logger level remotely (with JULI). To clarify: I do *not* want to change the handler levels remotely -- just the Logger levels. Example: Set Handler to FINE at deploy time and tune Logger level remotely via JMX at runtime. Use the attached files for the steps below. @@ Without JULI - can set Logger level but not Handler level @@ Start Tomcat 5.5.12 with: "-server -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8081 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false" Open your browser and invoke the servlet; it's output: Manager: null Remote: true Manager Class: class java.util.logging.LogManager Logger through manager: true Logger through bean: true Logger level: null Run CommandLineManagementConsole (or use JConsole and check if LoggerNames contains "de.LogTestServlet"); it's output: Logger through remote connection: true @@ with JULI - can set Handler level but not Logger level @ Start Tomcat 5.5.12 with: "-server -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8081 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager" Open your browser and invoke the servlet; it's output: Manager: org.apache.juli.ClassLoaderLogManager Remote: true Manager Class: class org.apache.juli.ClassLoaderLogManager Logger through manager: true Logger through bean: true Logger level: FINE Run CommandLineManagementConsole (or use JConsole and check if LoggerNames contains "de.LogTestServlet"); it's output: Logger through remote connection: false
Created attachment 16686 [details] Test Servlet
Created attachment 16687 [details] Class to access the Logging MBean remotely
Created attachment 16688 [details] {webapp.base}/WEB-INF/classes/logging.properties
Created attachment 16689 [details] {webapp.base}/WEB-INF/classes/logging.properties
Created attachment 16690 [details] {catalina.base}/conf/logging.properties
Created attachment 16691 [details] {webapp.base}/WEB-INF/web.xml
logging.properties files are either the default ones or adjusted from the one here: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/logging.html Controlling Log Levels remotely with JConsole: http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html#LoggingControl JMX command-line parameters for remote access: http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html#remote
This JMX feature cannot be made to work with non core loggers. Why did you file a bug ? This is users@tomcat material ...
This feature can work with non core loggers. Looking at the source I think it is a "feature" of your implementation -- so WONT-FIX would be a better resolution .) As I see it both getLogger(final String name) getLoggerNames() return the Loggers registered under the calling Thread's Classloader. A solution would be to iterate classLoaderLoggers and return the aggregate (getLoggerNames) or search the aggregate for a logger (getLogger). But I'm not into the details of the implementation yet.
Yes, and you know the classloader for which you want to change the logger how exactly ? Forget it. Obviously, everything about jul is completely pluggable, so you can write your own log manager quite easily.
I know this is totally unrelated to this bug, but I don't want hunt through the bug db for half an hour just to get in touch with you again :) I just downloaded the source distribution from http://apache.autinity.de/tomcat/tomcat-5/v5.5.12/src/apache-tomcat-5.5.12-src.zip Unzipped it. Went into the JULI "home" dir. And invoked ant there; the build failed because it could not find "MANIFEST.MF" there. Removing manifest="${build.home}/conf/MANIFEST.MF" from the build file fixed it; probably either the line should be removed or a MANIFEST.MF should be supplied with your source distribution.