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 (3) JCL Throws Exception Rather Than Logging To java.util.logging (22%) ----------------------------------------------------------------------- 9,10,20,26,28,30,32 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? 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? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
