Chris, I think you are absolutely right, if JULI's LogManager was registered. In that case LogManager.reset() will go to ClassLoaderLogManager which will only work on loggers that were associated with the thread's context class loader before. The JDK implementation of the LogManager will however simply reset all logging.
Thanks, Henning Am Mittwoch, den 10.02.2010, 14:07 -0500 schrieb Christopher Schultz: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Henning, > > On 2/10/2010 4:47 AM, Henning wrote: > > Yes I did [use a separate ClassLoader]. The code below was meant to be a > > simplified example. I > > created a bug report on that in the meantime: > > https://issues.apache.org/bugzilla/show_bug.cgi?id=48716 > > Could you post some of your code? Be sure to set the ContextClassLoader > for the thread used to start the context. > > > JULI however calls LogManager.getLogManager().reset() as a side effect > > of a context stop() (e.g. when removing an app from tomcat) so that all > > JDK logging config gets reset :-( > > If the class loading was done correctly, this should reset the > context-private copy of the LogManager class, not the top-level one. > > > If you are involved with JULI, you might be able to provide a good > > solution. > > Unfortunately for you, I am not involved in JULI. I've never tried to do > anything like you're doing, but I would bet that it can be done without > changes to JULI or Tomcat. > > > I thought testing whether the current LogManager is indeed > > JULI's before calling reset could be a remedy. > > That's not a bad idea, but again, I think the ClassLoader usage is key, > here. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAktzA9QACgkQ9CaO5/Lv0PC11ACglz7siPv42uQ937T5XuY5ZCW2 > XYcAnAiRgIk6afiCzZCY3XQX+igjDnPX > =aw2D > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
