DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35774>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35774 ------- Additional Comments From [EMAIL PROTECTED] 2005-07-19 12:19 ------- I think I've managed to get my head around this one... Simon's analysis seems good but I'd like to add a few random comments... Exotic ClassLoaders ----------------- When used in a JCA, this is a use case where JCL really can't gather enough information to configure itself correctly. It's tough. It's good to have a solid use case for exotic classloading. I think when I was thinking about exotic classloaders, I thought that there was something that could be done for cases such as this: along the lines of recognizing that TCCL is busted and default to use the class classloader. Good point from Simon (though) that busted TCCL's should be not cached. Would need to think about performance but maybe bad performance is better than total refusal to run... Static Binding ----------- If I've understood this correctly, the client and server jars would use static binding to determine the LogFactoryImpl to be use. There's a certain amount of convergence here: DON_QUIXOTE and SLF4J. I'd prefer to implement a long term solution (prune back to a minimal set of statically bound classes and interfaces) rather than a short term fix (client and server jars). I'm not so religous as Simon about jar proliferation but he's right that more jars need more explaination and so more quality documentation. I've been wanting for a while to look at using byte code engineering to statically bind different discovery strategies. Michael Kopp's is an advanced use case. If he's using a child-first classloader then (hyopthetically) he could just run the enhancer over all the jars and rewire the discovery. Maybe one day I'll find the time to get this working... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]