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

[David M. Lloyd]

Forgot that not everyone is a committer, so...

Anonymous SVN link: http://anonsvn.jboss.org/repos/sandbox/david.lloyd/logmanager

- DML

On Thu, 13 Dec 2007 21:43:33 -0600 "David M. Lloyd" <david.lloyd at redhat.com> wrote:

> 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 at redhat.com> 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development