On Sun, 27 Mar 2005 20:31:19 +0200, Simon Kitching <[EMAIL PROTECTED]> wrote:
What happens when multiple independent webapps use j.u.logging? Can each webapp have its own personal logging configuration file? And if so, is logging correctly cleaned up when the webapp is undeployed?
Yes, it should work ok. At the moment, it simply uses a weak hashmap, which I think should be enough.
Hmm.. beanutils and jcl have both tried to use a weak hashmap keyed by classloader to store per-webapp data, and in both cases this has been shown to result in a memory leak on undeploy. See the recent thread on singletons etc. wrt beanutils and JCL.
We'll see how well this works soon, as it is used to provide logging defaults in the new Tomcat build (the previous defaults were using java.util.logging as well, but with the default implementations, and consequently didn't do anything useful).
I´ll just point out there are two quite independent logging concepts here: logging of internal container details, and logging by webapp code.
I´m quite sure you can use j.u.logging for Tomcat´s internal logging.
No, I can't, the configuration is too restrictive, etc. That's what we were doing by default in previous Tomcat 5.5 releases.
Sorry, I meant using the j.u.util logging API from the code, but backed by the JULI implementation.
Have you also looked into the issues relating to what happens when a webapp uses j.u.logging API to log messages (or when some library that app depends upon does so)?
I'd recomend you look at it. Why do you think it would cause problems ?
Well, it is quite a tricky thing to get right when the logging implementation classes are loaded via a classloader shared across multiple webapps.
I will definitely have a look at the JULI code as soon as I am back from holiday.
Regards,
Simon
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
