IntelliJ에서 외장 Tomcat 연동 방법

연동 과정

1. Apache Tomcat 설치

https://tomcat.apache.org/

원하는 버전의 Tomcat을 설치하자. 참고로 Tomcat 9부터는 Java 8부터 지원하니 이를 고려해 설치하도록 하자.

 

2. 본인의 OS 환경에 적합한 파일 다운로드

필자는 64-bit Window를 활용하기 때문에 64-bit Windows.zip 파일을 다운로드하였다.

이렇게 파일 다운로드를 하고 원하는 위치에 압축을 풀어놓자.

 

개인적으로는 "C:\" 바로 아래에 Tomcat을 위한 (영어 이름) 폴더를 만들고 그곳에 압축을 푸는 것을 추천한다.

이유는 2가지 있는데 먼저 여러 가지의 Tomcat 버전을 사용해야 할 경우 관리하기가 편해지며, 두 번째로 가끔 Path에 한글이 들어가는 경우가 있는데 한글이 들어갈 경우 에러가 발생하거나 정상적으로 동작하지 않을 가능성이 있으므로 이 가능성을 아예 없애버리는 것이다.

 

3. Run > Edit Configurations나 오른쪽 위에 "Add Configurations" 클릭

 

4. 왼쪽 위 + 선택 & Tomcat Server > Local 선택

 

5. Configure... 클릭 & 이전에 설치하여 압축 해제한 Tomcat 선택

 

5-2. 추가 설정 수행

• After launch : 활성화 시 서버가 재시작 완료되었을 때 선택한 브라우저(Chrome)에서 자동 연결함
• VM Options : JVM에 Parameter로 전달하여 VM의 동작방식 및 시스템 속성을 정의하는 Option
  • X 옵션 : JVM Heap Memory, Permanent Generation, Direct Buffer 크기 지정 등
  • D 옵션 : 전역 시스템 속성 정의
  • -[Option]Key = Value
    • (ex) -Dfile.encoding=UTF-8
    • 필자가 많이 활용하는 Option으로 이걸 활용하면 Tomcat을 실행시킬 때 Log에서 한글이 깨지는 문제를 막을 수 있다.
• On 'Update' action : 서버를 재시작시킬 때 라디오 버튼으로 선택해 놓을 Default 동작 설정
• HTTP Port : Project를 SSL 없이 http로 실행할 경우 사용할 Port Number
• JMX Port
  • JMX : 실행 중인 Application 상태를 모니터링하고 설정을 변경할 수 있게 해주는 API
  • 2018.3.4 IntelliJ부터 Spring Boot Local JMX Connector를 사용하므로 JMX Port는 거의 변경하지 않음. 만약 외부 JMX를 활용하고 싶을 경우 JMX가 실행되고 있는 Port Number를 입력해 주면 됨

 

6. 아래 Fix 버튼 클릭(혹은 Deployment 탭 클릭) & :war exploded Artifact 선택

여기에서 "[Project명]:war"와 "[Project명]:war exploded"의 차이를 알아볼 필요가 있다.

일단 :war는 "war:war"와 동일하며 ":war exploded"는 "war:exploded"와 동일하다.

 

기본적으로 Gradle이나 Maven 같은 Build Tool을 활용하여 빌드 과정이 수행된다는 것은 알고 있을 것이다.

이때 빌드 과정은 "Compile, Test, Packaging, Deploy & Run" 과정으로 되어 있다는 것까지 이전에 배웠다.

 

이때 war, exploded는 Packaging 및 Deploy에 관련된 작업 내용이라고 할 수 있겠다.

즉 Compile 결과물을 "어떻게 배포시킬 것인가"에 관련된 내용인 것이다.

 

◎ package(archive) - :war

기존에 알고 있던 일반적인 과정이다.

Compile 결과물들을 Archive(.war, .ear, .jar 등) 파일로 만들어 WAS에 배포하는 것으로써 압축된 실행 파일은 WAS(Apache Tomcat)에 의해 압축이 풀려 실행된다.

 

원격 서버에 1개 파일(Archive 파일)만 보내면 되므로 전송 시간을 줄일 수는 있지만 파일들을 압축하는 시간 및 압축을 푸는 추가 시간이 요구되므로 파일이 많을수록 압축 해제 시간이 오래 걸린다.

 

Archive 파일을 보내기 때문에 만약 파일이 변경될 경우 Compile, Packaging, Deploy&Run 과정까지 모두 진행되어야 한다.

즉, 서버를 무조건 껐다 켜야 한다. 왜냐하면 Run 과정에서 압축 해제가 일어난 후 실행되기 때문이다.

 

◎ exploded(expanded) - :war exploded

Archive 파일을 압축 해제한 형태의 디렉터리로 배포하는 것이다.

즉, Archive 파일을 만들기 위해 압축하는 과정을 생략하고 바로 빌드 결과물들을 WAS에 보내는 것이다.

 

exploded는 Java Source Code가 존재하는 공간과는 별도의 디렉터리에 원본 소스를 복사하여 빌드 결과물을 만든다.

이렇게 만들어진 빌드 결과물을 압축 해제 과정 없이 바로 WAS에서 실행시키면 되는 것이다.

 

원격 서버에 배포할 시 exploded는 모든 디렉터리와 파일들을 일일이 보내야 하므로 빌드 결과물이 많을수록 전송 시간이 오래 걸릴 것이다.

 

그렇다면 파일이 많아질수록 전송시간이 Archive 파일 압축 해제 시간보다 압도적으로 커질 텐데 위에선 왜 exploded를 사용하는 것일까?

 

이는 Tomcat Server가 Local에 존재하기 때문이다.

이미 Tomcat Server가 Local에 존재하고 있기 때문에 파일을 따로 전송시킬 필요가 없다. 즉, 파일의 전송시간은 사실상 0이 되는 것이다.

따라서 압축 해제시간도 들지 않고 전송시간도 들지 않아 일반 package(:war) 보다 빠르게 실행시킬 수 있는 것이다.

 

추가로 Compile 및 Build만 새로 하고 배포만 하면 변경사항이 바로 적용되므로 서버를 껐다 켜지 않아도 변경시킨 Source Code를 적용시킬 수 있다고는 하는데 적용 안 되는 경우가 있어서 그냥 서버를 껐다 켜서 변경 사항을 적용시키는 것을 추천한다.

 

◎ in-place

Source Code 전체 또는 일부를 그대로 배포하는 것이다.

추가적인 복사 과정이 불필요하지만 WAS가 Runtime시 생성하는 파일이 소스 코드와 섞일 수 있다는 문제가 존재한다.

(이런 문제 때문에 거의 활용하지 않는 것 같다)

 

7. Application Context 변경

아마 Artifact를 클릭하면 자동으로 Application Context 값이 설정될 것이다.

 

이는 여러 프로젝트를 동시에 실행시킬 때 충돌이 없도록 하기 위해서 설정되어 있다.

 

하지만 필자는 대부분 1개 프로젝트만 실행시킬 것이고 애초에 ㄷProejct가 "http://localhost:8080/"을 기본으로 이후 URL Path로 잡아줬기 때문에 /로 바꿔주었다.

---

Error 1 : Can't load IA 32 bit .dll on an AMD 64-bit platform

◎ 에러가 발생한 원인

일단 에러 구문을 직역해 보자.

AMD 64-bit Platform에서 32-bit dll 파일을 가지고 올 수 없다.

 

즉, Platform 역할을 하는 JVM이 64bit인데 DLL은 32bit 이므로 호환되지 않아 발생하는 문제라고 할 수 있겠다.

그렇다면 dldl 파일은 어디에 존재할까?

 

바로 사용하는 Apache Tomcat 디렉터리 내부에 존재한다.

즉, dll 파일을 사용하여 Apache Tomcat을 구동시킬 때 32 bit로 WAS로 동작하는데 이 위에 64 bit JVM을 동작시키려 하니 문제가 발생하는 것이다.

 

◎ 해결방법

Java와 Apache Tomcat의 Bit 환경 설정이 일치하지 않은 것이므로 2개의 Bit 설정이 일치하도록 새롭게 파일을 다운로드하는 것이다.

 

일단 컴퓨터 CPU가 32-bit라면 Apache Tomccat과 JVM 역할을 하는 jdk를 32-bit로 다운로드하면 해결될 것이다.

 

하지만 CPU가 64-bit일 경우 무조건 64-bit Version으로 다운로드하는 것을 추천한다.

 

이유를 알기 위해선 32bit와 64bit의 차이를 알아볼 필요가 있다.

여기서 말하는 Bit는 CPU가 데이터를 처리하기 위해 사용하는 Register의 크기를 말하는데 이 레지스터는 소량의 데이터와 처리 중인 중간 결과물을 기억해 두는 고속의 전용 영역을 의미한다.

당연히 Register의 공간이 클수록 더욱 많은 중간 결과물과 데이터를 저장할 수 있을 것이므로 Register 크기가 클수록 속도가 빨라질 것이다.

(32 Bit : 4GB까지 인식 가능, 64 Bit : 16 엑사바이트까지 인식 가능. 1 엑사바이트 = 100만 테라바이트)

이런 이유로 32bit보다는 64bit 프로그램을 사용하는 것이 속도 면에서 훨씬 좋은 것이다.

 

추가로 32bit 프로그램들을 아직도 지원하는 이유는 (하위) 호환성을 위해서이고 과거 Intel CPU 칩셋 번호가 x86이었기 때문에 32bit를 x86이라고도 부른다.

---

Error 2 : 이 쿠키를 위해, 유효하지 않은 도메인 .xxx이(가) 지정되었습니다.

◎ 에러가 발생한 원인

정말 정신 나갈뻔한 에러이다.

이 에러는 "DispatcherServlet" 쪽에서 나는 에러라 Log로도 출력되지 않아 회사 선배 중 디버깅 기능을 잘 활용하시는 분이 찾아주셨다.

 

Tomcat 8.5로 넘어가면서 기본 쿠키 Processor가 Legacy Cookie Processor에서 RFC 6265 Cookeie Processor로 정책이 변경되었다.

 

출처 : https://meetup.nhncloud.com/posts/209

여기에서 가장 중요시 봐야 하는 설정은 "도메인 속성"이다.

 

먼저 쿠키 Domain이 무엇인지부터 알 필요가 있다. 쿠키는 특정 Domain 범위 내에 존재하는 여러 서버들 사이에 쿠키를 공유할 수 있는데 이때 Domain 속성을 통해 공유를 진행한다.

쿠키 Domain은 현재 쿠키가 어떤 서버로 전송되어야 하는지를 지정해 주는 값인 것이다.

 

예를 들어보자. 네이버의 도메인은 "www.naver.com"이고 네이버 블로그의 도메인은 "blog.naver.com"이다.

이때 네이버에서만 활용하고 싶은 쿠키도 있을 것이고 네이버 블로그에서만 활용하고 싶은 쿠키도 있을 것이며 두 사이트에서 공유하는 쿠키도 있을 것이다.

네이버에선 "네이버 메인에 접속하는 User"를 쿠키로 저장하고 네이버 블로그엔 "블로그에 접속하는 User"를 쿠키로 저장하며 네이버 및 블로그에는 모두 "로그인한 User 정보"를 쿠키로 저장하고 싶을 수 있을 것이다.

 

이때 쿠키 도메인을 각각 "www.naver.com", "blog.naver.com", "naver.com"으로 지정하는 것이다.

그리고 "naver.com" 쿠키 도메인을 사용하면 네이버 및 네이버 블로그에서 공유할 수 있는 쿠키를 만들 수 있는 것이다.

 

기존 Legacy Cookie Processor는 도메인 속성이 "."으로 시작했나 RFC6265는 "."으로 시작하면 안 된다.

예를 들어 naver.com을 쿠키 도메인으로 설정할 경우 Legacy는 ".naver.com", RFC6265는 "naver.com"로 사용한다.

 

문제는 이 쿠키 도메인 때문에 발생했다.

회사 CMS는 Tomcat 7이 많이 활용되었던 시기에 개발이 진행되었던 프로젝트이다. 당연히 Tomcat 7에서 활용했던 Legacy Cookie Processor 기준으로 Domain 속성을 설정했고, "."으로 쿠키 도메인이 시작하였다.

 

문제는 필자가 프로젝트를 Tomcat 8.5로 실행시켰다는 것이었다. 당연히 Cookie Processor가 RFC6265로 변경되었다.

 

RFC6265 ver.8.0은 쿠키 도메인이 Legacy Cookie Processor 형식이더라도 맨 앞에 있는 "."을 제거하는 방식으로 자동 처리하였지만 8.5 Version부터는 앞에 .이 붙어 있을 경우 Legacy에 관련된 Exception을 발생시켰다.

이  때문에 정상적으로 서버가 켜지지 않았던 것이었다.

(선배들은 Tomcat 8.4로 실행시켰기 때문에 이런 문제가 발생하지 않았던 것이었다.)

 

◎ 해결 방법

해결 방법은 총 3가지이다.

먼저 설정한 쿠키 도메인에 맞는 Tomcat 버전을 활용하는 것이다.

 

두 번째로 Apache Tomcat 8.5 이상의 버전을 활용할 때 .(dot)으로 쿠키 도메인이 시작하지 않도록 Source Code나 설정값을 변경하는 것이다.

 

마지막으로 사용하는 Apache Tomcat 디렉터리에 있는 conf/context.xml에 아래와 같은 설정을 추가해 주는 것이다.

<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor"/>

CookieProcessor로 Default 설정인 RFC6265가 아닌 Legacy를 사용하도록 변경해 주어 기존 프로젝트를 활용할 수 있게 만든 것이다.

---

Error 3 : Since Maven 3.8.1 http repositories are blocked

◎ 에러가 발생한 원인

Maven 3.8.1에서 신규 추가된 기능 때문이다.

Maven now disables all insecure http://* mirrors by default.

 

간단히 해석하자면 Maven은 http를 통해 미러링 할 경우 안전한 프로젝트가 아니라고 생각하여 아예 프로젝트 실행을 불가능하게 막아버리는 것이다.

 

로컬 환경에서 개발을 진행할 경우 대부분 "http://localhost:8080"으로 접근할 것이다.

 

IntelliJ에서는 기본 Maven을 Bundled(Maven 3)으로 설정하고 있으며 이 Bunlded(Mavne 3)은 3.8.1 버전이다.

따라서 3.8.1 버전에 추가된 신규 기능 때문에 실행에 문제가 발생하는 것이다.

 

◎ 해결 이유

pom.xml에는 Maven 버전 같은 빌드 환경에 대한 기록이 모두 적혀 있다.

따라서 IntelliJ 설정값을 변경하여 pom.xml(or properties 파일)에서 Maven에 대한 설정을 읽어와 빌드를 수행하도록 하면 이 문제는 해결될 것이다.

 

추가로 이렇게 할 경우 설정 파일(pom.xml or properties 파일)에 적혀 있는 환경 그대로 빌드를 수행하므로 에러 없이 더욱 깔끔한 빌드 및 실행이 가능하다.

 

File > Settings를 클릭하고 Maven을 검색한다.이후 Maven Home path를 "Use Maven Wrapper"로 설정하면 된다.이렇게 설정하면 설정 파일에 적혀 있는 환경 그대로 빌드 및 프로젝트 실행이 가능해진다.