: Being able to override the default implementation fortunately allows to : implement the must-have feature you describe as the "ClassLoader specific : LogManagerManager", I agree; however, I think it should have been in the : default implementation. I view this as a major regression from the previous : de-facto standard (aka log4j).
take this to the logical conclusion: if JUL's LogManager did implicitly allow configuration per ClassLoader, then in the case of Something like Solr, where each core constructs a ClassLoader for loading plugins, you could wind up with a plugin jar mucking up the logging (for it and other plugins loaded by teh same class loader) and ignoring the LogManager you choose for Solr. Security and configuration and flexibility have to start at the root of the tree and be passed down. the "root application" (servlet container in our case) needs to say "i'm going to use a LogManager that allows code i load at runtime to pick it's own LogManager". The converse is also true, a servlet container needs to be able to say "i'm not going to allow webapps to log willynilly, all messages must get funneled through me via a central config." ... it just so happens that the later is the default. : There are organisations where IT responsability ends at application : security/start/stop (the more apps/servers running, the more likely & : common); people in charge of the application content & usage do monitor : their logs. In this case, the unified logging pipeline (ala Websphere/JUL : for instance) is in fact inconvenient (fortunately, WAS also support : commons/log4j/...). : : IT logs are expected to only contain container/services logs and : applications are highly encouraged (aka expected) to deal with their logging : needs themselves. Then the IT people setting this expectation should be providing you the basic tool you need to satisfy it: a servlet container using a LogManager that will delegate to a LogManager (or LogManager configuration) per webapp. -Hoss
