Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=pAS3PDsaX1HcgsBcbvRYp+KfPqelhs/1sMwQ5KIOazY/stgwZdtBJkd1wicIUNquoL9pYcmOc3rLHwn/fhPUNSK25xIAYZBmZugQwmsfTBxFzdKxrWgDgIoQAr2VHib4mWlysxran+IflhBJDywDNnjbdFWDo/I/mnMD+yYCR+0=
  ;
Message-ID: <20050425065919.69017.qmail@web31714.mail.mud.yahoo.com>
Date: Sun, 24 Apr 2005 23:59:19 -0700 (PDT)
From: Brian Stansberry <bes_commons_dev@yahoo.com>
Subject: Re: [logging] issues highlighted by analysis
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: 6667
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


--- robert burrell donkin
<robertburrelldonkin@blueyonder.co.uk> wrote:
> here are my results obtained by comparing the theory
> with the current
> behaviour. 
> 
> (1) JCL Behaves As Expected (50%)
> ---------------------------------
> 1,2,3,4,7,8,11,12,15,16,17,18,19,23,27,31
> 
> (2) JCL Throws Exception Rather Than Logging To
> Log4J (28%)
>
-----------------------------------------------------------
> 5,6,13,14,21,22,24,25,29
> 

On 14, shouldn't JCL logging be via j.u.l?  The
caller's classloader only has access to the api.jar,
so it shouldn't be possible to load Lo4jLogger.

On 13 a similar situation applies, because with
parent-first loading the api.jar in the parent is
going to be the JCL that does discovery.  It will see
its own Log4j but have no wrapper class.

> (3) JCL Throws Exception Rather Than Logging To
> java.util.logging (22%)
>
-----------------------------------------------------------------------
> 9,10,20,26,28,30,32
>
 
When I ran these, for every child-first case the
sysout output said the caller was defined by the child
loader.

[java] Caller        defined by CHILD  class loader

For 18, 20, 26, 28, 30 and 32, the overview says
caller should be loaded by the parent.  Haven't had a
chance to try to see why, but this could be the cause
of some problems.

> i've categorised them by the differences between
> what should happen in
> theory with the current behaviour. 
> 
> i am going to create tests cases based on the ones
> in demonstration
> which should allow accurate diagnosis of the causes.
> however, i have a
> good idea of some of the causes and would like to
> start a discuss about
> possible solutions in advance.
> 
> i don't propose to do anything about those in #1 ;)
> 
> i suspect that many of failure cases in #3 are
> caused by JCL being able
> to load one or more of the appropriate classes by
> name from a
> classloader but then throw an exception when they
> are not compatible.
> IMHO this behaviour is counter-productive. in this
> case, rather than
> throwing a runtime exception, JCL should conclude
> that log4j is actually
> not really available and use java.util.logging
> instead. 
> 
> any opinions about changing JCL so that this
> approach is adopted?
>

+1.  If the chosen logger cannot be loaded, a message
to System.out and/or System.err should be recorded,
and then fall back to JDK logging, and then to
SimpleLog.  I don't think logging frameworks should
throw runtime exceptions.

 
> i suspect that many of the failure cases in #2 are
> caused by JCL using
> an incompatible class from the context classloader
> when one is available
> from it's own classloader. IMHO the presence of a
> version of Log4J on
> the context classloader should be a good enough
> indication that the user
> intended log4j to be discovered for JCL to try to
> load log4j from it's
> own classloader if the other fails.
> 
> opinions?
>

Sounds right, but need to think on this some more. 
Don't know why but something tells me I should.

I think your comments both point in the direction of
LogFactoryImpl's biggest weakness.  Currently
discovery is really divided into 3 methods
(newInstance, getLogConstructor and getLogClassName),
arranged in a stack.  The problem is if
getLogClassName discovers a class the methods higher
on the stack can't handle, they have no choice but to
throw an exception.

I think a better approach would be more like the
following:

1) newInstance checks if logConstructor is null.
2) if null, call a "private Log
discoverLogImplementation(String logName)" method,
passing the category name of the log.
3) discoverLogImplementation not only tries to find
the  class and c'tor, it actually instantiates the log
and returns it.  By doing this it can ensure that
discovery actually works, including taking steps like
the ones you recommend above.
4) If discoverLogImplementation succeeds in
instantiating a Log, it sets instance variable
logConstructor so in the future the newInstance method
can instantiate logs directly.

I roughed out an implementation along these lines
tonight and got no exceptions on your demonstration
tests.  JCL worked as expected in all except 13, 14,
18, 20, 26, 28, 30 and 32.  I think it was right in 13
and 14 as well, and am hoping there is a problem in
the test fixture on the others.

Brian

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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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