[
https://issues.apache.org/jira/browse/LOGGING-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated LOGGING-98:
-----------------------------------
Fix Version/s: 1.1.0
> [logging][PATCH] Improvements to LogFactoryImpl
> -----------------------------------------------
>
> Key: LOGGING-98
> URL: https://issues.apache.org/jira/browse/LOGGING-98
> Project: Commons Logging
> Issue Type: Improvement
> Environment: Operating System: other
> Platform: Other
> Reporter: Brian Stansberry
> Priority: Minor
> Fix For: 1.1.0
>
> Attachments: LoadTest.diff, LogFactoryImpl.diff, LogFactoryImpl.diff,
> LogFactoryImpl.diff, LogFactoryImpl.java, LogFactoryImpl.java,
> LogFactoryImpl.java, LogFactoryImpl4.diff, LogFactoryImpl4a.diff,
> LogFactoryImpl4b.diff, LogFactoryImpl5a.diff, LogFactoryImpl5b.diff,
> LogFactoryImpl6a.diff, LogFactoryImpl7c.diff, LogFactoryImpl8c.diff,
> LogFactoryImplC.diff, LogFactoryImplD.diff
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
