DO NOT REPLY [Bug 34661] New: - [logging][PATCH] Improvements to LogFactoryImpl

[bu...@apache.org]

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: commons-dev@jakarta.apache.org
        ReportedBy: b_stansberry@hotmail.com


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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org