java.util.logging.Logger 를 이용하여 로깅 하는것 정리

목적
java.util.logging.Logger 를 이용하여 로깅을 하면서 생겼던 문제점들과 처리 방법에 대한 기록
(세팅의 경우에는 하단 정리한 것 참조, 자바 api참조)

1.
Logger안에는 LogManager가 존재하고 이 LogManager가 Logger들을 가지고 관리하게 된다.
LogManager 의 경우에는
LogManager lm=LogManager.getLogManager();
를 통해 생성한다.

LogManager에 임의로 셋팅한 Logger를 추가할 수 있고
LogManager 를 통해 전체 셋팅을 변경할 수도 있다.
lm.readConfiguration(InputStream);

Logger 는 getLogger 호출 시 마다 LogManager 안에 해당 logger가 존재하지 않으면
새로 생성하여 LogManager 안에 넣어둔다.
LogManager에 생성된 logger는 삭제할 방법은 없는거 같다.

가령 1,000 개를 생성하면 LogManager는 1000개를 가지고 있게 된다.

기본적으로 Logger를 생성하면 상위 Logger의 속성을 따라가게 된다.
(설정properties파일 을 따라가게됨)

2.
getAnonymousLogger() 의 경우 logManager 가 관리하지 않음

확인해본 바로는
LogManager 에서 getAnonymouse 로 가져온 logger object 는 별도 관리하지 않는다.
그러므로 getAnonymouse 할떄마다 새로운 logger 가 나온다.

LogManager 안을 뒤져서도 안의 값을 찾을 수 없다.


3.
개별 java-project에서 Logger를 사용하여 로깅을 하였다.
그리고 이를 jar로 묶어서 was에서 사용하기 위해 web-project 에 올려서 사용하였다.
그리고 properties 를 강제로 읽게 하여 사용하였는데 문제점 발생

문제점 : was가 java.util.logging.Logger로 로깅을 하고 있었는데 이때 logger 의 properties 정보를 바꾸면
모든 logger의 properties 정보가 바뀌게 됨.

해결방법
이 방법이 해결이 맞는지는 모르겠으나 사용하려는 logger 들을 별도로 생성하여 별도로 셋팅 하였음

최초 호출되는 진입점 시점에서 Logger 가 존재하는지 체크
        LogManager lm=LogManager.getLogManager();
        if(lm.getLogger("myLogger")==null) {
        }

한번 셋팅하면 그 셋팅이 유지되게 됨

4.
FileHandler를 사용할 경우 .lck 파일이 생성되는 점과 .1 같은 넘버링 된 파일 확장자의 다른 파일들이 생기는 문제
일단 .lck파일이 생성되는건 해당 파일을 물고 있기 떄문이다.
Logger가 사라지지 않고 계속 존재하기 떄문에 문제가 되는거 같다.

.1 같이 넘버링된 파일이 존재하는건 FileHandler 안의 구현 자체가 그렇게 되어 있기 떄문이다.
여러 스레드가 동시에 접근할 경우 파일을 별도로 만드는거 같다.

나 같은 경우 이렇게 되면 로그파일에 안전성을 추가되나 다수의 스레드가 접근할 경우 너무 난잡하게 되는 경향이 있어서
일단 StreamHandler 를 사용하였다.
StreamHandler의 경우 FileOutputStream 만 인자로 넘겨주면 해당 파일로 로그를 만든다.