commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: svn commit: r381879 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
Date Wed, 01 Mar 2006 21:10:03 GMT
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.

Unfortunately for backwards-compatibility reasons the existing behaviour
for a services file should probably stay as-is, ie falling back to the
default implementation.

Regards,

Simon


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