Affects Version/s: None
Fix Version/s: 1.1.0
Operating System: other
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
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
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.