------- Additional Comments From [hidden email] 2005-06-12 05:38 -------
(In reply to comment #33)
> I then recorded the differences in results between the parallel cases. There
> were 3 kinds of differences:
> 1) (Cases 5, 6, 17, 21, 22, 25, 29) Here the original case discovered log4j
> and the parallel case discovered JDK logging. This is simply because in these
> cases the TCCL is the system classloader, so LogFactory cannot find
> commons-logging.properties. Within the scope of what I'm testing here (cases
> where code deployed in a child loader is trying to configure JCL), I don't
> regard this as a "fixable" problem.
I wanted to follow up on this a bit, to see what would happen if
commons-logging.properties were at the parent level instead of the child.
(Rather than changing the code, I cheated a bit and had the run target in the
ant file set a JVM property; this should have the same effect, but if I'm
thinking wrong please let me know).
I tested against a class that reflects my recent patches. 11 cases (Nos. 1-4,
9, 10, 13, 14, 18, 26 and 30) fail with an LCE. In all these cases, in Robert's
original version JDK logging is discovered.
These results tell me that users who are forced to set the LOG_PROPERTY to get a
library other than log4j or jdk discovered will have significantly different
behavior from those who can just put log4j.jar on the classpath. I don't think
such a big difference is right; I'm thinking the 3rd approach mentioned above is
the way to go.
BTW, in getConfigurationValue() there is a cut-and-paste bug in the system
property check where the LOG_PROPERTY constant is checked instead of the
property passed to the method. I'd submit a patch, but don't want to confuse
things with the other two patches just submitted.