(getting a bit big so breaking up the topic) On Sun, 2005-04-24 at 23:59 -0700, Brian Stansberry wrote: > --- robert burrell donkin
<snip> > > 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. cool. (i'm notorious for not rushing) > 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. +1 with the current implementation, getLogClassName has to be bullet proof. > 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. that sounds like a good plan. one thing to remember is that there is quite a lot of code in the various instantiation methods that has been added to cater for unusual environments over time. therefore modifying the control flow sounds like the right approach. > 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. that's possible. (i'll discuss this in another thread.) once you're happy to left other people take a look at your code, add it to a bug report. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
