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=34661>. 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=34661 ------- Additional Comments From [EMAIL PROTECTED] 2005-06-12 02:19 ------- Created an attachment (id=15378) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15378&action=view) patch to allowFlawed/.../LogFactoryImpl 8c (Attached is a patch to the file that would result from applying the previous "7c" patch to the LogFactoryImpl now on the "allowFlawed' branch.) I was concerned that there might be pretty significant differences in JCL behavior depending on whether a user included a commons-logging.properties file, so I played with the demonstration harness to see what would happen. Basically here's what I did: -- Added a parallel test case for each of the 32 existing cases. -- In each parallel case, replaced any usage of log4j.jar with logkit.jar. -- In each parallel case, added to the child loader classpath a commons-logging.properties file specifying logkit. 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. 2) (Cases 3 and 4) Here the original case discovers JDK logging but in the parallel case JCL fails with an LCE. This is because in these cases LogKitLogger is defined by parent, logkit.jar by child, so LogKitLogger cannot resolve logkit.jar. The LCE seems fairly legitimate to me, particularly in case 3 where the caller is defined by the child loader. The user stated the log library they want, which can't be loaded. This can easily be remedied by adding logkit.jar to the parent classpath as cases 7 and 8 show. 3) (Cases 20, 28 and 32) Again the original case discovers JDK logging but in the parallel case JCL fails with an LCE. But here the problem is the incompatible Log interface problem. In these cases, I don't think it is valid for JCL to _always_ throw an LCE. If the user wants an LCE thrown, they can set the ALLOW_FLAWED_HIERARCHY_PROPERTY to false. The current behavior penalizes users who want to run logkit, avalon, etc. by leaving them no way to avoid the LCE. I can think of 3 approaches to handling the 2nd and 3rd category problems. The first is simply to strip out the throwing of an LCE from discoverLogImplementation -- just let normal discovery proceed if the user specified class can't be instantiated. This approach prevents LCEs in the 2nd and 3rd category cases. However, it doesn't allow failure when it might be appropriate. The attached patch takes the 2nd approach. It has handleFlawedDiscovery and handleFlawedHierarchy set a flag if they are invoked but are configured to ignore the flaw. If this flag is set, discoverLogImplementation knows the specified adapter was loaded but there was a problem the user wants to ignore. In that case, it allows normal discovery to proceed. This approach only resolves the 3rd category problems. Cases 3 and 4 still fail with LCEs. A 3rd approach would build on the attached patch. It would add another ALLOW_...._PROPERTY letting the user specify what they want to happen in cases 3 and 4. Any thoughts? -- 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]
