Hi Adrian, Sorry I should have read the jboss logging page through to the end before posting :-(.
On Thu, 2005-07-28 at 11:43 +1200, Simon Kitching wrote: > > > > JBoss also has its own trivial logging abstraction (factory + wrapper) > > that does not have these problems and allows other logging targets, > > e.g. JDK logging see the bottom of > > http://wiki.jboss.org/wiki/Wiki.jsp?page=Logging > > Interesting approach. I personally don't like this for several reasons: > * The logging configuration is stored in a container-level file. That > means that someone needs container administration access in order to > change the logging configuration for a component, yes? I think a > component's logging config should be modifiable by the component's > administrator. > * As the page indicates, there is a problem when multiple components > happen to use the same logging categories. Deploying separate test and > uat instances must be interesting (or having multiple developers > trying to deploy their personal versions to the same container). The > workaround is to define separate Appender objects for each alternate > deployment URL, and filters to then ensure that the component only > logs to its associated appender(s). This would seem to work, but it > isn't very elegant or efficient is it? > * the logging configuration can't reference any custom Level classes > or Appender classes or Layout classes defined in the component. If > this were to be allowed, then you would have bidirectional references > from the *static* logging info in log4j back into the components which > would block undeploy. > > However if components were just to include log4j.jar in their > WEB-INF/lib directory you wouldn't need to go to all these complicated > lengths to work around the problem of having a shared logging > installation; proper per-component logging would just work. Wouldn't > that be easier? This all applies to the first setup described for jboss logging, where log4j is only present in the container's path. Later there is a reminder that log4j can be put into the application ("component"), though this does require tweaking jboss' classloader config info so that local log4j instances aren't ignored. Why isn't the log4j-in-component approach the recommended approach? I guess logging is one of those issues where the responsibility for configuring it depends on circumstances. Sometimes the application deployer should be responsible for this [eg if there is a dedicated maintenance team for that application], and sometimes the container sysadmin should be responsible for this [where monitoring of all apps is centralised]. Using the RepositorySelector-with-log4j-in-the-container approach is also documented. However this does suffer from some limitations: as described above it can't load any custom classes from the application to define appenders, layouts, filters, levels, etc. or undeploy stops working properly. This isn't something that is a problem when log4j is deployed within the component/application. The last point about redirecting java.util.logging into log4j is interesting. If it redirects into log4j-in-the-container then all the same issues listed above apply. If it redirects into log4j-in-the-component then surely the undeploy problem occurs. Regards, Simon ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
