commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [logging] a candidate explanation for "Log4JLogger does not implement Log"
Date Mon, 23 May 2005 19:58:14 GMT
On Sun, 2005-05-22 at 15:59 -0700, Brian Stansberry wrote:
> --- robert burrell donkin
> <robertburrelldonkin@blueyonder.co.uk> wrote:
> 
> > On Sun, 2005-05-08 at 01:06 +1200, Simon Kitching
> > wrote:
> > > Hi All,
> > > 
> > > I've been working for quite a while now to try to
> > figure out why users
> > > of JCL have been getting the "Log4JLogger does not
> > implement Log"
> > > message.
> > > 
> > > I think I've finally really understood the cause.
> > If this is really
> > > obvious to everyone, please let me down gently :-)
> > 
> > one thing which i have learnt from working with JCL
> > over the years is
> > that nothing is ever obvious :)
> > 
> > more than anything we need clear explanations of
> > what happens and why. 
> > 
> 
> +1.
> 
> I understood (and had since forgotten) from working
> with Ceki Gulcu's JCL analysis that the problems
> happened when code loaded a parent loaded tried to log
> with the TCCL in effect, but your  discussion of why
> such a call would be made -- outside a test fixture :)
> -- makes the real world issue much clearer (and easier
> to remember).
> 
> <snip>
> >> Ok, so what is the solution?
> >
> >
> >i would like to split this question into two. 
> >
> >
> >i believe (as indicated in the analysis document)
> that the correct
> >behaviour in these cases is for JCL to recognise that
> log4j is not
> >viable (for this configuration) and default to
> java.util logging. this
> >is a little unsatisfactory but i don't see a
> reasonable technical
> >solution for these configuration.
> >
> 
> One unsatisfactory aspect is that instead of throwing
> an exception with a nice message and stack trace,
> logging would mysteriously be done using an unexpected
> logging library.  But Simon's recent work on adding
> diagnostics should help mitigate this drawback.

i think that this comes down to a question of philosophy. 

the consequences of throwing an exception are usually pretty fatal for
an application. personally, i think that we'd be doing most users (who
just want to run their application) a favour by ensuring that discovery
throws as few exceptions as possible. i hope that diagnostics and a good
troubleshooting document would prove a good enough substitute for those
who want to choose a particular logging system.

then again, this opinion has traditionally been in the minority so i'd
be happy to go with the consensus on this issue...

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message