On Wed, 2006-03-01 at 20:47 +0000, robert burrell donkin wrote:
> On Wed, 2006-03-01 at 02:49 +0000, [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
