Erik Hatcher wrote: > > It seems to me Sun left it wide open for a thousand implementations > to flourish, actually. What's to prevent a ClassLoader specific > LogManagerManager from being put into the mix? Nothing - that's what > JULI does. >
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). Instead of having "one" standard as it should have been, we end up with one proprietary solution per container trying (or not) to complement it with some "slightly extended constructs" to cope with configuration. Erik Hatcher wrote: > > Container writers do need to ensure they funnel all of > their plugged in components to a unified pipeline to be good logging > citizens. > I see a difference between "container plug-ins/core services" where the unified pipeline allows these to be good logging citizens and applications where it is almost an hindrance. 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. If we consider these environments as application colocating/hosting, container management stops before the application functional boundary. Logging is a functional aspect, it is a feature of an application and therefore should not be tied to container management. As it stands, JDK logging is certainly appropriate & sufficient for the container & its services but definitely lacks a standard per-application self-configurability mechanism to cope with these common deployment schemes. Of course, all of this is moot when you have the luxury of configuring the container yourself or as you please but also makes the JDK logging choice a tad elitist. -- View this message in context: http://www.nabble.com/logging-through-log4j-tp13747253p16993293.html Sent from the Solr - Dev mailing list archive at Nabble.com.
