[jboss-dev] My logging ultimatum

[David M. Lloyd]

On Wed, 12 Dec 2007 16:34:00 +0100
Adrian Brock <abrock at redhat.com> wrote:

> Assumptions...
> The devil is always in the details. :-)

My point being that calling it broken without citing examples doesn't
help the discussion - but, since then, you've done so.  So, moving
onward...

> > > The deadlocking problems can only get worse
> > > in the delegating LogManager solution.
> > > You now have competing synchronization
> > > strategies, e.g. jdk and log4j
> > 
> > What deadlocking problems?  What strategies?  If you do a custom
> > LogManager, there *is* no synchronization strategy as far as I see -
> > you're completely in control. Has it been demonstrated that the JDK api
> > is broken?
> 
> See other post for two examples of "unfixed bugs".
> 
> Implementing the whole LogManager/Logger api
> is almost certainly more code than jboss-logging-spi
> and you'd need a seperate (non jdk) api to create something other
> than the default logger implementation.

Yes, this is true, but these are two different situations.

> // static method == not overriddable
> private static final Logger log = Logger.getLogger(className)

Fair point...  But the Logger.getLogger() method (and the corresponding
LogManager.demandLogger() method) are the only bits that an implementer
would not have full control over.  It's not too hard to work around.

> Your only reason for doing it is so you can have a
> zero jar deployment (i.e. use the JDK by default)
> but this is potentially broken as demonstrated.
> 
> In fact, this changes the burden for clients.
> 
> Previously a client without log4j or a log4j configuration
> did no logging,
> 
> Now they will have to do some configuration
> to avoid the potentially broken JDK calls.

If a user is using a container of nearly any sort (well, except for
ours), then using JDK logging will go to the server log.  If the user
is running standalone, then they still have a choice - include zero
jars (and get logs on System.err) or include one jar to get whatever
the logging behavior it is that they're after.  I don't see this as any
better or worse than always requiring one jar and getting no logs -
they could always just include a jdk-logging-null.jar and get the same
thing.

> > 
> > > Conclusion: An unstable server is not a valid
> > > trade-off to fix some aethestic considersation
> > > about distributing a few small jars.
> > 
> > Sure I'll agree with that, but as far as I can see it hasn't been
> > demonstrated that JDK logging would make your server unstable.
> 
> We've had lots of problems with logging causing server hangs
> in the past. 
> 
> Logging is pervasive, it's not something
> we should be changing on a whim.
> 
> And the correct question is the opposite:
> "Is JDK logging demostratively as stable as what we've got now?"

I'm not advocating to change the logging backend on the server - that's
what Scott has done with his change, which has nothing to do with what
I propose.

I am proposing the following changes, and nothing more:

1) Always provide support on JBossAS for libraries and user code that
use JDK logging, which forwards log messages into the server log.  This
means install a LogManager. If we want to continue to use log4j, we
should use a LogManager that forwards to log4j.  Anything intrinsic to
the container should continue to use the JBoss common logging framework
without any change, which works just fine for that purpose.

2) Always provide support on JBossAS for libraries and user code that
use log4j.  If we drop log4j, then we should continue to provide an
emulation API or something, because there are clearly lots of things
that still use it.

3) People developing new libraries or JBoss.org projects or whatever
should at least *consider* using JDK logging if they need to log
messages.  Or, if the objection to JDK logging is insurmountable, then
at least make the logging framework optional somehow.  Though I believe
that JDK logging can be used as a viable alternative to clogging and
friends.

> You are arguing for a change, convince me
> that a "few extra" java classes on the classpath
> is a big problem that requires this "major upheaval".
> (opinions in quotes :-).

Heh, well it doesn't -require- major upheaval per se, that's just the
kind of guy I am.  I just can't wake up in the morning without some
kind of major upheaval.

> P.S. Attacking my argument as only opinion is
> a logical fallacy:
> http://en.wikipedia.org/wiki/Ignoratio_elenchi
> and certainly not a "factual contribution to the discussion". :-)

Fair.

- DML