[
https://issues.apache.org/jira/browse/LOGGING-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved LOGGING-89.
------------------------------------
Resolution: Won't Fix
Considering the available alternatives (log4j, logback, slf4j) and the state of
JCL, this proposal is not going to happen anymore.
> [logging] Enterprise Commons Logging : Globalization & more
> -----------------------------------------------------------
>
> Key: LOGGING-89
> URL: https://issues.apache.org/jira/browse/LOGGING-89
> Project: Commons Logging
> Issue Type: Improvement
> Environment: Operating System: All
> Platform: All
> Reporter: Richard A. Sitze
> Priority: Minor
> Attachments: ASF.LICENSE.NOT.GRANTED--EnterpriseLogFactory.java,
> ASF.LICENSE.NOT.GRANTED--EnterpriseLog.java
>
>
> IBM would like to open a discussion within the Jakarta commons community
> on evolving the Jakarta Commons Logging (JCL) API's to support Enterprise
> level logging functionality. We recognize the value that a "logging
> implementation independent API" brings to open source component
> development, and would like to work with the community to accomplish this
> goal.
> We present a set of requirements as a baseline for the discussion, a
> proposal for meeting these requirements, a number of points of discussion,
> and attached are two Java source files that correspond to the discussion
> below.
> Requirements:
> We recognize that the community has an overriding
> requirement:
> A.1. Evolution: maintain compatibility with the
> current LogFactory/Log interfaces.
> We have ONE primary requirement:
> A.2. Globalization
> Having opened the door, we'd also like to propose a few
> other requirements:
> B.1. Functional alignment with JSR-47 concepts.
> B.2. Fix fragile configuration problems - Currently
> the user has NO idea which impl is in effect.
> All the default/fall back behavior means that in
> the end we have an apparent non-deterministic
> logging implementation. Errors in config file
> names, classpath errors, classpath ordering,
> etc., can all change the behavior... with no
> idea which is in effect.
> The fundamental problem with the current factory
> is that it is dependent on "passively"
> identifying a logging implementation.
> We propose one solution below, but would ask a
> more general question: any new bright ideas?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
