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
--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat