A simple logmanager implementation [Was: Re: [jboss-dev] My logging ultimatum]

I created a simple log manager that could be the basis for... something. The URL is: https://svn.jboss.org/repos/sandbox/david.lloyd/logmanager It's just four classes - one of which is a copy of the WeakValueHashMap class from jboss common core, relocated to the other package. Though in practice one could just depend on that project; this is just for the sake of illustration. Anyway, features of this minimalist log manager: * Every node in the logger heirarchy holds only weak references to its children (solves Sun bugs 4811930, 6274920) * There's no configuration whatsoever (solves JBAS-2087) * LogManager.addLogger() is a no-op (always returns false) (solves Sun bug 6487638) * The stupid class/method inferring crap in LogRecord is suppressed * Late binding is simple - just add a Handler to the root logger whenever you like Other things that could be done: * Add security permissions such that an application can configure or get loggers for only sections of the global heirarchy (allows applications to add Handlers for their log messages, but not "steal" messages for applications or components that they don't have permission to) - this would be pretty easy I think * Dunno, probably other cool stuff Notes: * The log manager disallows getting a complete listing of Loggers - call this a security feature if you like :-) * LogManager.getLogger(xxx) always returns a Logger, even if one didn't exist before Anyway, comment if you like. On Thu, 13 Dec 2007 12:00:50 -0800 Scott M Stark <sstark(a)redhat.com&gt; wrote: > The main problem I have had with JUL integration in the past is that it > requires hooking into the core configuration at the extension classpath > level. I had to replace the JUL manager to allow for configurations that > loaded loggers from application/thread context class loaders. Not that > this is hard, its just something that has to be part of the server > bootstrap process rather than something that can be done via late binding. > > Its been a while since I looked at integration though. With the other > mega-thread about i18n/JUL integration, we need some tasks to > investigate what we can/want to do in terms of allowing seamless > integration from framework JUL usage to be mapped to server loggers, and > what the jboss logging spi is. > > Bela Ban wrote: > > > > > > Tim Fox wrote: > >> +100 to David on this. > >> > >> The point here is about reducing number of dependencies. Another > >> meta-framework (like jboss common logging) is not a good solution > >> IMHO. This is particular important for OEMs who may want to use our > >> project embedded in their own applications (this is what we intend to > >> do for JBM2) > >> > >> If JDK logging can allow you to delegate to you log tool of choice by > >> deploy time configuration, and the bugs in JDK logging are only bugs > >> in the JDK logging implementation which you can bypass anyway, then we > >> should all be using JDK logging surely. > >> > >> I'm certainly going to look at refactoring JBM to use JDK logging. > > > > Me too. If Adrian and/or Scott can tell me that this will not cause > > issues in the appserver because they can wrap/redirect my calls to JUL > > to log4j (or their own logging impl), then that would be fine. Otherwise > > I'd probably wait for JDK 7 > > > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development