commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [Logging] Commons against Lumberjack...
Date Mon, 03 Feb 2003 19:12:28 GMT


On Mon, 3 Feb 2003, David Orriss Jr wrote:

> Date: Mon, 3 Feb 2003 10:06:22 -0800
> From: David Orriss Jr <dave@davenet.net>
> Reply-To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
> To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
> Subject: Re: [Logging] Commons against Lumberjack...
>
> On Friday, January 31, 2003 8:18 PM,
> Craig R. McClanahan <craigmcc@apache.org> wrote:
>
> >
> > There was a problem with the way that commons-logging was identifying
> > whether this was a JDK 1.4 system or not, which would cause a problem
> > on a JDK 1.3 system with an alternate JSR 47 implementation
> > installed.  This has been corrected in nightly build 20030201 of
> > commons-logging.  Could you please try again with this build and
> > report the results?
> >
> >
>
> Craig,
>
> We downloaded the nightly build and while yes, things *do* work now, this isn't
> quite the fix we had in mind.  The modification you wrote was to change
> isJdk14Available() as follows:
>
>     /**
>      * Is <em>JDK 1.4 or later</em> logging available?
>      */
>     protected boolean isJdk14Available() {
>
>         try {
>             loadClass("java.sql.Savepoint");
>             loadClass("org.apache.commons.logging.impl.Jdk14Logger");
>             return (true);
>         } catch (Throwable t) {
>             return (false);
>         }
>     }
>
> The result of this is that if we using JSR 47-compliant logging in JDK 1.3, we
> no longer have  a failure in struts.  *However* we still wanted the struts
> logging to go against our JSR 47-compliant libraries.  The result of your fix is
> that Commons Logging completely usurps the Lumberjack JSR 47 libraries.
>
> I take it these means that Commons Logging and Lumberjack are not compatible and
> probably never will be...?
>

That's not the intent -- what I'd like to have, though, is a proposed
patch that you've shown accomplishes that goal.  The original bug report
only talked about changing which class to check for in order to gauge JDK
1.4 presence or not.

> --
> David Orriss Jr.
>

Craig

Mime
View raw message