On debugging more I found that the issue was because logback has a check to not register a bean if its already registered. This creates a issue with glassfish since glassfish creates two classloaders for each web application. The first one is a temporary one which is later destroyed. The problem arises because the logback JMX mbean is instantiated with this temporary classloader and registered with the mbean server. Since re-registration is not done any operations on the logback jmx mbean through jconsole fail. A workaround to this is to not add the jmxconfigurator tag in the configuration file and register the logback jmx bean manually in a servlet context listener. LogbackUser wrote:
Is there a way to delay the start up of the jmx mbean? While debugging glassfish source code (build 43) I found that the mbean refers to the webappclassloader instance which was destroyed and hence the below error. I am suspecting that the JMX MBean gets started before the glassfish server is properly started and hence it gets an incorrect reference to the classloader.
Any help would be appreciated.
Thanks,
LogbackUser wrote:
I am using glassfish 3.1 as my application server and I have enabled JMX by adding the <jmxConfigurator/> tag in the logback.xml. I am able to view the logback classic mbeans on jconsole but invoking operations like getLoggerLevel fails with an error - "Problem invoking getLoggerLevel : java.lang.IllegalStateException: WEB9031: WebappClassLoader unable to load resource[java.lang.Object], because it has not been started or was always stop...."
Accessing the "LoggerList" attribute also does not give any output. Statuses attributes shows the status messages though. Is there anything I am missing in terms of configuration?
-- View this message in context: http://old.nabble.com/Logback-JMX-Operations-and-Attributes-tp31423995p31496... Sent from the Logback User mailing list archive at Nabble.com.