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: svn commit: r381879 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
Date Wed, 01 Mar 2006 22:20:55 GMT
On Thu, 2006-03-02 at 10:10 +1300, Simon Kitching wrote:
> On Wed, 2006-03-01 at 20:47 +0000, robert burrell donkin wrote:
> > On Wed, 2006-03-01 at 02:49 +0000, skitching@apache.org wrote:
> > > Author: skitching
> > 
> > <snip>
> > 
> > > --- jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
(original)
> > > +++ jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
Tue Feb 28 18:49:34 2006
> > > @@ -465,6 +465,20 @@
> > >                          + "]. Trying alternative implementations...");
> > >              }
> > >              ;  // ignore
> > > +        } catch(Exception e) {
> > > +            // This is not consistent with the behaviour when a bad LogFactory
class is
> > > +            // specified in a services file.
> > 
> > +1
> > 
> > IMHO the services behaviour is preferable. if the user cares about this
> > failure then they can turn on diagnostics to discover the cause. 
> > 
> > can anyone think of a good reason not to remove the re-throw?
> 
> I'm currently -0 on removing the re-throw.
> 
> When code is doing "auto-discovery" of some kind and discovers an
> unusable class it is reasonable for it to continue its discovery
> process. However when the user has *explicitly* indicated that a
> particular class should be used I don't think falling back to something
> else is correct.
> 
> The WAS issue does fall somewhere in the middle; it's the container not
> the user that is explicitly requiring TrLogFactory. Nevertheless it's an
> explicit command to use that class and I don't think we should ignore
> that.

AIUI WAS is not the only container to adopt this approach. i've heard of
some others which do the same. in these cases, the user deploying the
application made no active choice. throwing an exception means that JCL
is effective preventing the application from being run in that
container. often, users will not have even heard of JCL before it
prevents an application they want to run from executing. this kind of
user unfriendly approach is one reason why JCL has such a poor
reputation.

it is rare for users to use the system property. those users who want to
use a custom LogFactory and set the system property should be aware of
JCL and should have read the documentation (or they wouldn't know about
this option). they should be running with diagnostic logging on.

throwing an exception makes things slightly easier for a small minority
of expert users at the expense of large numbers of users who are not
familiar with JCL and just want to run their application. 

why not add another flag so that expert users who want this behaviour
can opt in?

- 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