On Wed, 12 Dec 2007 19:46:17 +0100
Adrian Brock <abrock(a)redhat.com> wrote:
But your proposal is for the appserver to do lots work
for what I will describe again as little more than a
aesthetic reason.
What about all the libraries and user programs that use JDK logging
today? Are we saying they're second-class citizens, and that they have
to configure a separate logging system? Even if I start using the
jboss logging facade right now, this problem still exists. Either
we're going to support them, and handle JDK logging, or they're SOL.
Quite frankly we've got better things to spend are
time on than writing, testing and supporting
a JUL->log4j adapter - even if it was technically possible
e.g. weaving all your classes that do Logger.getLogger()
to replace the implementation.
It doesn't have to be that complicated. Just installing a simple
LogManager would do the trick... I've even got one lying around
somewhere that does exactly this. It's not complicated.
This is the part of the argument you just don't seem to be
getting.
Just because you don't want to use a very simple facade,
others are forced to jump through hoops with more complicated
facades or accept a less than optimal solution.
I'm not forcing anyone to do anything, just saying we ought to support
JDK logging, which is not unreasonable I think.
"You cannot argue somebody out of a position using reason
if they never reasoned themselves into it in the
first place" :-)
OK.
Fact: we don't support JDK logging today in JBossAS.
Fact: it's simple to make an adapter LogManager for mapping JDK
logging to log4j.
Fact: There are libraries and user programs - even within JBossAS -
that use JDK logging today.
Is it so odd that I come to the conclusion that we should add support
for JDK logging? I'd even argue that, by providing a simplified
LogManager, we'd increase server stability by factoring out those bugs
mentioned earlier.
I don't think this is unreasonable.
- DML