박성훈의 웹개발

배경

운영중인 프로젝트 JDK 버전을 1.6에서 1.7로 버전업하는 작업을 진행하게 되었다. 버전 변경을 위해 pom.xml의 maven-compiler-plugin의 속성인 <source>와 <target>을 1.7로 수정하였고, TC를 수행하였는데 다음과 같은 에러가 발생하였다.

원인

문제는 PowerMock과 JDK 1.7간 버전 충돌이였으며, 그 이유는 JDK 1.7부터 바이트코드를 검증할 때 StackMapTable을 반드시 체크하도록 변경 되었기 때문이다. 이 방식은 기존 바이트코드 검증 방식과 호환성이 유지되지 않는다.

(개인적으로 PowerMock을 통해 static 영역을 mocking 하는 테스트 케이스가 더 문제라 생각한다.)

해결

자바 옵션에 -XX:-UseSplitVerifier 추가하여 해결하였다. 해당 옵션은 기존 방식으로 바이트코드를 검증한다는 의미로서, 사실 해결책이라기 보단 회피 방법이라고 보는 것이 좀 더 적합할 것 같다.

또한 JAVA 8에서는 해당 옵션이 deprecated 되었으니, 최종적으로 PowermockRunner를 사용하는 테스트 케이스를 수정하는 것이 좋을 것 같다.

참고자료

• http://stackoverflow.com/questions/15253173/how-safe-is-it-to-use-xx-usesplitverifier
• http://blog.triona.de/development/jee/how-to-use-powermock-with-java-7.html

소개

grep은 "global regular expression print"의 약어로, "파일 전체에서 정규 표현식과 일치하는 것을 출력하라"는 의미를 가지고 있다.

문자열 검색

-r 옵션는 recursive로서 서브 디렉토리까지 검색을 하게 된다.

파일에서 검색

grep "검색하고 싶은 문자열" [파일명]

디렉토리에서 검색

grep "검색하고 싶은 문자열" [디렉터리명]

grep -r "검색하고 싶은 문자열" [디렉터리명]

대소문자 구분 없이 검색

grep -r -i "검색하고 싶은 문자열" [디렉터리명]

정규 표현식 검색

정규 표현식은 특수한 기호를 사용해 검색하고 싶은 내용을 유연하게 표현하는 방법이다.

이름 찾기

grep -r -i -E "(sunghoon|성훈)" [디렉터리명]

핸드폰 번호 찾기

grep -r -i -E "0[0-9]{1,2}-[0-9]{3,4}-[0-9]{4}" [디렉터리명]

소개

sudo는 "substitute user do"라는 뜻으로서, 일부 또는 전체 명령어를 ROOT 계정 또는 다른 계정의 권한으로 실행할 수 있도록 한다.

su vs sudo

su 명령어는 다른 계정으로 전환을 한다. 사용이 필요한 명령어가 있어 ROOT 계정으로 전환을 하고 명령어 수행 했더라도 계속 접속이 유지되므로 보안에 문제가 발생하게 된다. sudo 명령어는 특정 작업에만 수행할 수 있는 권한을 부여해 주는 것이므로 이러한 보안 문제점을 방지할 수 있다.

사용법

sudo [실행할 명령어] 형태로 사용이 가능하다. 명령어를 입력 후 엔터키를 입력하게 되면 본인의 비밀번호를 묻는다. 비밀번호를 정상적으로 입력하게 되면 /etc/sudoers에 등록된 사용자인지 검증을 한 후 명령어를 실행하게 된다.

ROOT 계정으로 수행

sudo useradd user1

다른 계정으로 수행

sudo -u sunghoon useradd user1

sudoers를 이용한 권한 부여

sudo vi /etc/sudoers 편집으로 권한을 추가할 수 있다. 추가할 계정의 권한을 파일 하단에 추가하면 된다.

user1 계정에 useradd, usermod 권한을 추가

user1 ALL=/usr/sbin/useradd,/usr/sbin/usermod

참고자료

• 리눅스 sudo - jsky10503님 블로그
• sudo를 응용한 권한 변경 - kes409 카페
• sudo 사용법 및 설정법 - guras님 블로그

현재 운영하는 시스템은 로깅 라이브러리로 log4j를 사용하고 있다. 1달 예상으로 신규 기능을 추가하는 작업을 진행하고 있는데, 이참에 log4j를 logback으로 전환하는 작업을 진행하였다.

logback이란?

logback은 log4j를 만든 개발자가 log4j를 토대로 새롭게 만든 Logging 라이브러리다.

우선 logback 사용시 얻게 되는 몇가지 장점에 대해 알아보자.

• log4j보다 약 10배 정도 빠르게 수행되도록 내부가 변경되었으며, 메모리 효율성도 좋아졌다.
• log4j때부터 광범위한 테스트를 진행한 경험을 가지고 있으며, logback은 더욱 높은 레벨의 테스트를 통해 검증되었다.
• 문서화가 잘 되어 있다.
• 설정 파일을 변경하였을 경우, 서버 재기동 없이 변경 내용이 자동으로 갱신된다.
• 서버 중지 없이 I/O Faliure에 대한 복구를 지원한다.
• RollingFileAppender를 사용할 경우 자동적으로 오래된 로그를 지워주며 Rolling 백업을 처리한다. (log4j를 사용했을땐 이 기능이 없어서 오래된 로그를 쉘 스크립트로 수동으로 삭제했었다.)

logback과 slf4j

logback을 사용하기 위해선 slf4j(simple logging facade for java)를 함께 사용해야 한다. slf4j는 facade 패턴을 적용한 로깅 프레임워크다. facade 패턴은 인터페이스와 비슷한 역할이라 할 수 있다. slf4j와 함께 개발자는 원하는 로깅 라이브러리를 선택해 사용하면 된다. 따라서 slf4j를 사용한다면 개발하면서 로깅 라이브러리 변경이 필요한 경우 쉽게 교체가 가능하다.

logback과 slf4j 라이브러리 관계 다이어그램

jcl-over-slf4j.jar와 log4j-over-slf4j.jar 라이브러리는 기존에 사용하는 코드 또는 써드파티 라이브러리가 다른 로깅 라이브러리를 사용하고 있을 경우, 이를 전환해주는 플러그인 라이브러리다. 로깅 라이브러리를 변경했을 경우나 오픈소스 라이브러리를 사용할 경우 잘 챙겨야 하는 라이브러리다.

pom.xml 설정

총 5개의 라이브러리를 dependency로 추가한다.

appender 설정

적용시 유의할 점 

만약 기존에 logback이 아닌 log4j가 slf4j와 연동되어 있을 경우, 반드시 slf4j-log4j12.jar 라이브러리를 제거해야 한다. slf4j-log4j12.jar 라이브러리는 slf4j가 log4j에게 로깅 처리를 호출하는 라이브러리인데, 이 라이브러리가 포함되어 있을 경우 다음과 같은 이슈가 발생한다.

• slf4j 멀티 바인딩 이슈 발생.
• log4j-over-slf4j.jar가 포함되어 있을 경우, 순환 오류로 인한 StackOverflowError 발생.

이 문제점들은 써드파티 라이브러리 dependency 추가시에도 발생할 수 있다. 써드파티 라이브러리에 slf4j-log4j12.jar가 dependency가 되어 있을 수 있다. 이 경우 반드시 exclusion을 해줘야 한다.

http://stackoverflow.com/questions/31044619/slf4j-log4j12-vs-log4j-over-slf4j

참고자료

• logback 사용해야 하는 이유 - beyondj2ee 블로그
• logging framework logback - beyondj2ee 블로그
• Log4j에서 LOGBack으로 마이그레이션 하기 - beyondj2ee 블로그
• SLF4J 로깅 처리 - sonegy님 블로그

인텔리J는 마우스 휠로 폰트 크기를 변경할 수 있다.

기본 옵션이 비활성화이므로 다음과 같이 활성화 옵션을 체크하면 사용할 수 있다.

Settings > 'wheel'로 검색 > 'Change font size (Zoom) with Ctrl + Mouse Wheel' 옵션 체크

문제점

아파치에서 에러 페이지 설정을 위해 다음과 같이 설정하였다.

ErrorDocument 404 /standby/notfound.html

그러나 이상하게도 크롬, 파이어폭스 브라우저에서는 404 에러 페이지가 잘 노출되나, IE 브라우저에서는 에러 페이지가 노출되지 않았다.

원인

이유를 알지 못해 계속 헤맸는데, 확인해보니 IE 브라우저 버그였다.

IE 브라우저는 512 바이트 이상이여야 404 에러 페이지를 노출하고, 512 바이트 이하일 경우 IE 브라우저에서 '웹 페이지를 찾을 수 없습니다' 메세지를 노출해준다.

해결

• 에러 페이지의 크기를 512 바이트 이상으로 설정하여 정상적으로 노출될 수 있도록 변경하였다.
• 또 다른 방법으로는 인터넷 옵션에서 'HTTP 오류 메세지 표시'를 체크 해제하는 방법이 있는데, 근본적인 해결책은 아닌듯 하다.
  
  

참고

각 에러코드마다 파일 사이즈가 다르니 다음 URL을 확인해보는 것도 좋을 것 같다.

http://www.404-error-page.com/404-error-page-too-short-problem-microsoft-ie.shtml

strings 명령어는 바이너리 파일에서 문자열을 추출하는 역할을 한다.

아파치의 mod_jk.so 버전을 확인하고 싶을 경우 다음과 같이 실행하면 된다.

예제) strings mod_jk.so | grep mod_jk/

mod_jk/1.2.31 (1026297)

mod_jk/1.2.31

윈도우즈에서 작업한 파일을 리눅스에서 열 경우 라인 끝마다 ^M 문자가 들어간 것을 볼 수 있다.

특히, 쉘스크립트 등에 포함이 될 경우 쉘이 동작하지 않게 된다.

아파치쪽 SSL 패스워드(SSLPassPhraseDialog) 설정과 톰캣쪽 환경설정 파일(setenv.sh)이 쉘로 되어 있었는데 ^M 떄문에 정상적으로 뜨지 않아 헤맴 -ㅅ-;

어쨌든 ^M을 없애는 방법은 간단하다.

vi 에디터를 열고,

:%s/^M//g

(^M은 단순 텍스트 입력이 아닌 Ctrl + v + m으로 입력하여야 한다.)

이렇게 명령어를 날려주면 된다.

length가 1이상일 경우 객체가 존재함을, 0일 경우 존재하지 않음을 의미한다.

if(jQuery("#specialistAnswer").length > 0) {
    jQuery("#specialistAnswer").val("Y");
}

JSESSIONID란?

- 톰캣 컨테이너에서 세션을 유지하기 위해 발급하는 키

- HTTP 프로토콜은 stateless하다. 요청시마다 새로운 연결이 생성되고 응답후 연결은 끊기게 되므로 상태를 유지할 수 없다.

- 따라서, 상태를 저장하기 위해서 톰캣은 JSESSIONID 쿠키를 클라이언트에게 발급해주고 이 값을 통해 세션을 유지할 수 있도록 한다.

동작방식에 대해서

1. 브라우저에 최초 접근시 톰캣은 Response 헤더에 다음과 같이 JSESSIONID값이 발급된다.

Set-Cookie: JSESSIONID=3CB361E0BE1A9A7DE7DB926DF0772BAE

2. 브라우저 재요청시 Response를 통해 받은 JSESSIONID를 Request 헤더의 쿠키에 값을 넣어 서버에 요청한다. 쿠키를 통해 JSESSIONID값을 전달받게 되면 서버는 새로운 JSESSIONID 값을 Response 헤더에 발급하지 않는다.

3. 클라이언트로부터 전달받은 JSESSIONID값을 기준으로 서버에서는 세션 메모리 영역에 상태를 유지할 값들을 저장할 수 있게 된다. (HttpSession 등)

유지범위

- 동일한 Full 도메인 (서브도메인이 다를 경우 쿠키가 유지되지 않으므로..)

- 포트번호는 달라도 무관하다.

한계

- 톰캣 컨테이너를 2대 이상 사용하게 될 경우 세션을 유지할 수 없다. 유지가 되기 위해서는 세션 클러스터링 환경을 구축하여야 한다.