commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis Lundberg (JIRA)" <j...@apache.org>
Subject [jira] Updated: (LOGGING-98) [logging][PATCH] Improvements to LogFactoryImpl
Date Tue, 29 Dec 2009 14:18:29 GMT

     [ 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.


Mime
View raw message