[ https://jira.jboss.org/jira/browse/JBLOGGING-44?page=com.atlassian.jira.p... ] Stan Silvert updated JBLOGGING-44: ---------------------------------- Attachment: bar.war -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBLOGGING-44?page=com.atlassian.jira.p... ] David Lloyd commented on JBLOGGING-44: -------------------------------------- There are two issues at play here. 1) Classloader isolation. When constructing a logger instance, JDK logging looks for the specified resource bundle in the TCCL (if it's not set, it uses the system CL); if not found there, it will snoop up the call stack until one of the stack frame's class' classloader contains a resource bundle with the appropriate name. If the class loader of each WAR is not isolated, then the resource bundle called "stantest" could be loaded from the wrong WAR. That is probably not the cause of what you're seeing though. 2) Logger uniqueness. JDK logging only constructs one instance of each logger. If you do Logger.getLogger(), it first checks to see if a logger of the given name already exists; if so, it returns it (even if it is already associated with a different resource bundle). There are two solutions to this problem. One is to use separate logger categories; this is the simplest solution. The other solution is to set up application-scoped log contexts by adding a jboss-logging.xml to your deployment which configures isolated logger contexts. This will cause isolated Logger instances to be created, however the system log handlers will not be used so you'd have to configure a separate output. This is a hard limitation of JDK logging, unfortunately. The way they handle resource bundles is pretty restrictive. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBLOGGING-44?page=com.atlassian.jira.p... ] Stan Silvert commented on JBLOGGING-44: --------------------------------------- Unfortunately, we can't use separate logger categories. This came up when I had two different versions of JSF in different WARs. The JSF version number showed incorrectly for one of the WARs because it looked at the resource bundle from the wrong WAR. The second solution doesn't sound good either since you have to configure a separate output. Any other ideas? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBLOGGING-44?page=com.atlassian.jira.p... ] Stan Silvert reassigned JBLOGGING-44: ------------------------------------- Assignee: David Lloyd (was: Stan Silvert) Assigning back to David so he will see my latest comments. For whatever reason, this works on Tomcat. Any ideas? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBLOGGING-44?page=com.atlassian.jira.p... ] Stan Silvert commented on JBLOGGING-44: --------------------------------------- Tomcat has some special voodoo. It works on Tomcat 5.5 and 6.0, but breaks on Jetty 6, AS6, and AS5. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBLOGGING-44?page=com.atlassian.jira.p... ] David Lloyd commented on JBLOGGING-44: -------------------------------------- The way the work around the issue is by keeping a separate set of loggers per classloader. When a logger is created, it's added to the set for the currently active TCCL. I don't think this solution will work for us, per se, because they rely on parts of the JDK logmanager which have inherent defects which we've disabled for this reason. However I might be able to come up with another solution based on this idea... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira