--- robert burrell donkin
<[EMAIL PROTECTED]> wrote:
> On Sun, 2005-05-22 at 15:59 -0700, Brian Stansberry
> wrote:
> > --- robert burrell donkin
> > <[EMAIL PROTECTED]> 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...
>
I've had a chance to look at the refactored version of
LogFactoryImpl I'd done, and it should be quite simple
to offer configurable options for this. The current
patch includes a method "recordCreationFailure" that
gets called when an adapter is "discovered" but fails
in the instance creation process. It's simple to
rename that method to something more general and add a
bit of logic to check a configuration option (i.e
system property or a property in
commons-logging.properties), and either throw a
LogConfigurationException or record the exception
using the new diagnostics code.
Which way to go as a default when the config option
isn't set is another question. Personally, I'm also
of the "logging should not fail an app" opinion.
It should also be fairly simple to cache any exception
that occurs during the discovery process, and then if
a Log is eventually found to record the cached
exception as a warning. This will provide feedback to
users who don't have the JCL diagnostics turned on.
Best,
Brian
> - robert
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
