[logging] Exception handling in LogFactoryImpl [WAS] a candidate explanation for "Log4JLogger does not implement Log"

[Brian Stansberry <be...@yahoo.com>]

--- robert burrell donkin
<ro...@blueyonder.co.uk> wrote:
> On Sun, 2005-05-22 at 15:59 -0700, Brian Stansberry
> wrote:
> > --- robert burrell donkin
> > <ro...@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...
> 

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:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> 
> 


		
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 

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

Re: [logging] Exception handling in LogFactoryImpl [WAS] a candidate explanation for "Log4JLogger does not implement Log"

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Mon, 2005-05-23 at 23:05 -0700, Brian Stansberry wrote:

<snip>

> 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.

that all sounds good

- robert


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