[jboss-dev] My logging ultimatum

[David M. Lloyd]

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