r's blog

Tomcat 7에서 운영 중인 프로젝트의 소스를 직접 수정 할 일이 생겨서

webapps에 Deploy된 프로젝트의 jsp 파일을 수정 했는데 오류가 발생했다.

오류 증상은 class not found나 pageEncoding="utf-8" 관련 오류였다.

특이사항은 jsp를 수정하면 수정된 내용으로 컴파일이 되지 않는다는 점이다.(jsp의 java와 class 파일이 생성되지 않음)

구글링 결과 Tomcat7의 일부 버전에서 해당 이슈가 있음을 okky에서 발견했다.

http://okky.kr/article/211745

위 게시글과 오류가 발생한 Tomcat의 마이너 버전은 달랐지만

그래도 혹시나 해서 버전업을 했는데 문제가 해결되었다..

어쩌면 Tomcat OS버전 마다(혹은 32bit, 64bit) 배포별 차이 일지도 모르겠다.

아무튼 테스트 내용은 다음과 같다.

Tomcat Windows Version x64

운영중인 Tomcat 버전 : 7.0.45 (오류 발생)

테스트 Tomcat 버전 : 7.0.42 (오류 발생)

테스트 Tomcat 버전 : 7.0.47 (정상 작동)

결론은 Tomcat7에서 배포된 jsp를 직접 수정시 class not found와 같은 오류를 만나지 않으려면

7.0.47 이상을 사용하자.

vo의 내용을 로그로 찍어보고 싶을때 일일히 getter를 호출하여 타이핑 하기 귀찮다.

물론 toString()으로 구현하여 메서드를 통해 찍는 방법도 있지만

매번 toString()을 재정의 하지 않아도 로그를 찍어 보려 Reflection으로 구현해 보았다.

http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/package-summary.html

그 외 Reflection 관련 링크

http://www.hanbit.co.kr/network/view.html?bi_id=1369

http://tutorials.jenkov.com/java-reflection/index.html

Effective Java 항목10의 타이틀은 "toString 메소드는 항상 오버라이드 하자" 이다.

딱 봐도 toString 메서드는 매우 중요해 보이는데 toString은 모든 객체의 부모인 java.lang.Object에 구현 되어 있다.

JavaSE 소스를 참고하니 위와 같이 구현 되어 있다. (at 사인과 16진수로 표기된 해시 코드 조합)

하지만 toString은 "간결해야 하지만 사람이 읽기 쉬운 형태의 정보 표현" 이어야 한다.(JavaSE6)

마치 배열의 경우 엘리먼트들의 문자열의 조합처럼 식별하기 쉬운 문자열을 예로 들 수 있다.

또한 toString 메서드는 println과 printf 메서드, 문자열 집합 연산자인 +, assert, 디버거 출력 등 여러 경우에 객체가 전달되면 toString 메서드가 자동으로 호출 된다.

결론적으로 toString을 잘 구현해 놓으면 예기치 않은 상황에 도움이 될 수 있다. 따라서 객체의 의도를 명확하게 문서화 또한 필요한 요소이다.

아래는 Effective Java에서 가져온 예제이다.

아래는 JavaSE6에서 가져온 HashMap.java의 toString 메서드 이다.

주제와는 동떨어진 내용이지만 위에서 언급된 String.format 메서드는 Jeus의 일부 버전에서 Servlet에 구현시 오류가 발생한다. 유용한 메서드인데 jeus 환경이라면 아쉬운 부분이다.

출처 : Effective Java