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 Summary: [logging][PATCH] Improvements to LogFactoryImpl Product: Commons Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Logging AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] Attached is a draft version of a proposed rework of the LogFactoryImpl discovery mechanism. This work is based on recent discussions on the commons-dev mailing list. The prime difference between the proposal and the existing class is that when the new discovery process "discovers" a potential Log implementation, it immediately attempts to create a Log instance. Only if an instance is successfully created is the implementation consider "discovered." The existing LogFactoryImpl considers an Log implementation to be discovered if it can load its class, but if there are any subsequent problems actually instantiating an object, the discovery process is already over and the code has no choice but to throw an exception. This proposed approach allows implementation of a couple of ideas Robert Burrell Donkin proposed on the dev list: 1) If discovery is able to load an implementation class using the TCCL, but instantiation fails, discovery continues with an attempt to load and instantiate the class using LogFactoryImpl's classloader. 2) If an implementation cannot be instantiated, no exception is thrown, but rather discovery continues to try other implementations, beginning with java.util.logging. In addition, the proposed code will write diagnostic messages to System.out and System.err if a Log class can be loaded but not instantiated. This is to help users understand why their desired Log implementation was not used. Some users may prefer to have JCL throw an exception. How this is handled could be made configurable; the proposed code at this point does not include this feature but it could be added. The intent of the attachment is to promote discussion/seek review, and since its a pretty significant refactor I've attached a complete file rather than a diff. To ease comparison the file includes a fair amount of commented out code from the prior version. Any comments or suggestions would be most appreciated. -- 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]
