commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 32618] New: - Enterprise Commons Logging : Globalization & more
Date Thu, 09 Dec 2004 22:44:18 GMT
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=32618>.
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=32618

           Summary: Enterprise Commons Logging : Globalization & more
           Product: Commons
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Logging
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: rsitze@apache.org


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?

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


Mime
View raw message