Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 47: Logging API Specification

Stage Access Start Finish
Final Release Download page 09 May, 2002  
Final Approval Ballot View results 04 Dec, 2001 17 Dec, 2001
Proposed Final Draft Download page 19 Sep, 2001  
Public Review Download page 30 Oct, 2000 29 Nov, 2000
Community Draft Ballot View results 03 Oct, 2000 09 Oct, 2000
Community Review Login page 09 Sep, 2000 09 Oct, 2000
CAFE   18 Dec, 1999 14 Jan, 2000
JSR Approval   11 Dec, 1999 17 Dec, 1999
Status: Final
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0


Description:
Define standard logging APIs for the error and trace logging.

Please direct comments on this JSR to the Spec Lead(s)
Team

Specification Leads
Star Spec Lead Danny Coward Oracle
Expert Group
  BEA Systems Ericsson Inc. IBM
  Lawrence, Jamie Oracle Soutter, Geoffrey
  Sun Microsystems, Inc. Tivoli

Updates to the Original JSR

The following information has been updated from the original proposal.

2010.02.15
Oracle took over as Maintenance Lead from Sun Microsystems.

Maintenance Lead: Oracle America, Inc.

Contact: Danny Coward

E-mail address: danny.coward@oracle.com

Telephone: +1 408 276 7049

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1: Identification

  Submitting Participant: Sun Microsystems

  Name of Contact Person: Graham Hamilton

          E-Mail Address: graham.hamilton@eng.sun.com

        Telephone Number: +1 408 343 1426

              Fax Number: +1 408 863 3195


  Submitting Participant: International Business Machines

  Name of Contact Person: Flavio Bergamaschi

          E-Mail Address: flavio@uk.ibm.com


Section 2: Request

2.1 Please describe the proposed Specification:

A specification for logging APIs within the JavaTM platform. These APIs will be suitable for logging events from within the Java platform and from within Java applications.

It is envisaged that:

  • It will be possible to enable or disable logging at run-time.
  • It will be possible to control logging at a fairly fine granularity, so that logging can be enabled or disabled for specific functionality.
  • The logging APIs will allow registration of logging services at run time, so third parties can add new log services.
  • It will be possible to provide bridging services that connect the Java logging APIs to existing logging services (e.g. operating system logs).
  • Where appropriate, the logging APIs will also support displaying high-priority messages to end users.

2.2 What is the target Java platform? (i.e., J2EE, J2SE, J2ME)

Java 2 Standard Edition.

2.3 What need of the Java community will be addressed by the proposed specification?

This specification is intended to allow field service engineers to obtain information to help diagnose application problems in the field. This includes configuration issues and performance problems as well as application failures. The APIs are intended to be used from both within the Java platform implementation and from within Java applications to provide logging and tracing information.

2.4 Why isn't this need met by existing specifications?

There are currently no general purpose logging or tracing APIs in the Java platform.

2.5 Please give a short description of the underlying technology or technologies:

Many operating systems provide some form of logging so that application programs can record key events, particularly on error conditions. It is desirable that the Java logging APIs should be able to interact with operating system logging services. In addition the logging APIs should enable logging to files or to network management services.

2.6 Is there a proposed package name for the API Specification?

java.util.logging

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.8 Are there any security issues that cannot be addressed by the current security model?

No.

2.9 Are there any internationalization or localization issues?

Yes. The APIs should permit internationalization of the log messages.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No. However it is anticipated that the implementations of various J2SE APIs will be updated to use the new logging APIs.


Section 3: Contributions

None.