--- robert burrell donkin <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
