패키지 java.util.logging

Java^TM 2 플랫폼의 코아로깅 기능의 클래스와 인터페이스를 제공합니다.

참조처:
설명

인터페이스의 개요

Filter	Filter 는, 로그 레벨이 제공하는 제어 이상으로, 로그 대상을 치밀하게 제어하기 위해서 사용됩니다.
LoggingMXBean	로깅 기능의 관리 인터페이스입니다.

클래스의 개요

ConsoleHandler	이 Handler 는, 로그 레코드를 System.err 에 발행합니다.
ErrorManager	ErrorManager 객체는 Handler 에 접속되어 로깅시에 Handler 로 발생하는 에러를 처리합니다.
FileHandler	단순 파일의 로깅 Handler 입니다.
Formatter	Formatter 는 LogRecord 의 포맷 처리를 지원합니다.
Handler	Handler 객체는,Logger 로부터 로그 메세지를 받아들여, 그것들을 export 합니다.
Level	Level 클래스는, 로깅 출력의 제어에 사용 가능한 일련의 표준 로깅레벨을 정의합니다.
Logger	Logger 객체는, 특정의 시스템 컴퍼넌트나 어플리케이션 컴퍼넌트의 메세지를 로깅 하기 위해서 사용됩니다.
LoggingPermission	SecurityManager 에 의해 실행되는 코드가 Logger.setLevel 등의 로그 제어 메소드의 어느쪽이든을 호출할 때, SecurityManager 가 체크하는 액세스권입니다.
LogManager	Logger 와 로그 서비스의 공유 상태세트를 관리하기 위해서 사용되는 단일의 글로벌 LogManager 객체가 있습니다.
LogRecord	LogRecord 객체를 사용해, 로그의 시스템와 개개의 로그 Handler 간의 로깅의 요구를 건네줍니다.
MemoryHandler	메모리의 순환 버퍼의 요구를 버퍼 처리하는 Handler 입니다.
SimpleFormatter	LogRecord 의 간단한 개요를 사람이 이해할 수 있는 형식에서 출력합니다.
SocketHandler	간결한 네트워크 로그 Handler 입니다.
StreamHandler	스트림에 근거하는 로그 Handler 입니다.
XMLFormatter	LogRecord 를 표준 XML 형식에서 포맷 합니다.

패키지 java.util.logging 의 설명

Java^TM 2 플랫폼의 코아로깅 기능의 클래스와 인터페이스를 제공합니다. 로깅 API 의 주된 목적은, 고객 사이트에서의 소프트웨어의 관리와 서비스를 지원하는 것입니다.

로그를 사용하는 주된 4 개의 목적은 다음과 같습니다.

1. 「최종 사용자와 시스템 관리 책임자에 의한 문제의 진단」. 이것은, 자원의 부족, 시큐리티 장해, 및 단순한 설정 에러 등, 로컬로 수복 또는 추적 가능한 자주 있는 문제의 간결한 로깅으로부터 구성됩니다.
2. 「필드 서비스 엔지니어에 의한 문제의 진단」. 필드 서비스 엔지니어가 사용하는 로깅 정보는, 시스템 관리 책임자가 필요로 하는 정보보다 큰폭으로 복잡하고 장황한 것이 될 가능성이 있습니다. 일반적으로, 그러한 정보를 가져오려면 , 특정 하부조직내에서의 추가 로깅이 필요합니다.
3. 「개발 조직에 의한 문제의 진단」. 필드에서 문제가 발생했을 경우, 경우에 따라서는 취득한 로깅 정보를 원의 개발 팀에 진단용으로서 되돌릴 필요가 있습니다. 이 로깅 정보는, 지극히 상세해 꽤 난해한 것이 될 가능성이 있습니다. 경우에 따라서는 이러한 정보에는 특정의 하부조직의 내부 실행의 상세한 트레이스가 포함됩니다.
4. 「개발자에 의한 문제의 진단」. 로깅 API 는, 개발중의 어플리케이션의 디버그를 지원하는 목적으로도 사용할 수 있습니다. 이것에는 아마, 타겟 어플리케이션에 의해 생성되는 로깅 정보나 저레벨 라이브러리에 의해 생성되는 로깅 정보가 포함됩니다. 다만, 이 사용 방법은 완전히 타당한 것입니다만, 로깅 API 의 목적은, 개발 환경내에 벌써 존재하고 있을 가능성이 있는, 일반적으로의 디버그 툴이나 프로 파일링 툴에 취해 대신하는 것이 아닙니다.

이 패키지의 주된 요소는 다음과 같습니다.

• 「Logger」:어플리케이션이 로깅 호출을 실시할 때에 사용하는 주요 엔티티입니다. Logger 객체는, 특정의 시스템 컴퍼넌트나 어플리케이션 컴퍼넌트의 메세지를 로깅 하기 위해서 사용됩니다.
• 「LogRecord」: 이것을 사용해, 로그 시스템와 개개의 로그 핸들러와의 사이의 로깅 요구를 건네줍니다.
• 「Handler」:메모리, 출력 스트림, 콘솔, 파일, 소켓 등, 다양한 출력 먼저 LogRecord 객체를 export 합니다. 이 목적을 위해서(때문에), 다양한 Handler 서브 클래스가 존재하고 있습니다. 추가의 Handler 가 Sun 이외로 개발되어 코어 플랫폼에 가세해 제공되는 경우가 있습니다.
• 「Level」:로그 출력을 제어하기 위해서 사용되는 표준 로그 레벨세트를 정의합니다. 프로그램은 다른 레벨에서의 출력을 무시해 일부의 레벨의 로그를 출력하도록(듯이) 구성할 수 있습니다.
• 「Filter」:로그 레벨이 제공하는 제어를 넘은, 로그 데이터에 대한 치밀한 제어를 실시합니다. 로깅 API 가 지원하는 범용 필터 기구를 사용하면, 어플리케이션 코드는, 임의의 필터를 접속해 로깅의 출력을 제어할 수 있습니다.
• 「Formatter」:LogRecord 객체의 포맷 처리의 지원를 제공합니다. 이 패키지에는 SimpleFormatter, XMLFormatter 의 2 개의 포매터가 포함되어 있습니다. 이것들은 각각, 로그 레코드를 plaintext, XML 로 포맷하기 위한의 것입니다. Handler 와 같게, 추가의 Formatter 가 Sun 이외로 개발되는 경우가 있습니다.

로깅 API 는, 정적 구성 제어, 동적 구성 제어의 양쪽 모두를 제공합니다. 정적 제어를 사용하면, 필드 서비스 스탭은, 특정의 구성을 설정한 뒤, 그 새로운 로깅 설정을 사용해 어플리케이션을 재기동할 수가 있습니다. 동적 제어를 사용하면, 현재 실행중의 프로그램내로부터 로깅 구성을 갱신할 수 있습니다. 또, 이 API 에서는, 시스템의 기능 영역 마다 로깅의 유효/무효를 바꿀 수도 있습니다. 예를 들어, 어느 필드 서비스 엔지니어는, 모든 AWT 이벤트를 추적하는 것에는 관심이 있어도, 소켓 이벤트나 메모리 관리에는 전혀 관심이 없는 경우가 있기 때문입니다.

null 포인터

일반적으로, javadoc 내에서 특히 기재가 없는 한, 메소드 및 생성자 은, null 인수를 건네받으면(자) NullPointerException 를 throw 합니다. 이 규칙에는 큰 예외가 1 개 있습니다. 그것은, Logger 클래스의 로깅 편리한 메소드 (config, entering, exiting, fine, finer, finest, log, logp, logrb, severe, throwing, 및 warning 메소드)는, 최초의 Level 인수 (존재하는 경우)를 제외하는 모든 인수로 null 치를 받는다, 라고 하는 것입니다.

관련 문서

제어 플로우의 개요에 대해서는, 「Java 로깅의 개요」를 참조해 주세요.

도입된 버젼:

1.4