WTP 버리고 embedded tomcat 활용하자.

2013-10-22 16:53

다른 개발자들은 intellij의 IDEA로 넘어가고 있는데 나는 아직까지 eclipse에 머물고 있다. 근 10년 이상 내가 프로그래머로 살아가는데 일조한 eclipse를 바로 버리기는 쉽지 않다. 그런 의미에서 eclipse에서 웹 서비스 개발할 때 WTP 활용할 때 불편한 점을 해소하고 embedded tomcat으로 접근하는 방법을 정리했다.

eclipse에서 embedded tomcat을 활용하는 방법에 대한 자세한 내용은 http://www.slipp.net/wiki/pages/viewpage.action?pageId=16711743 문서에서 참고할 수 있다.

---- 다음 세 가지가 내가 WTP를 사용하면서 불편했던 점이고, 이와 같은 개발 환경을 구축하게 된 이유이다. 지금까지 WTP를 사용하면서 불편함이 많았던 개발자들은 embedded tomcat 개발 환경으로 접근해 보기 바란다.

  • Context Path를 "/"로 설정하는 경우 JSP를 수정했을 때 jsp 컴파일 에러가 발생하는 경우이다. 이 경우 소스 코드에 문제가 있는 것이 아니라 WTP의 버그이다. 서버를 재시작하면 문제를 해결할 수 있다. 하지만 웹 애플리케이션을 처음 개발하는 경우 소스 코드에 문제가 없음에도 불구하고 소스 코드에 문제가 있는 것으로 생각해 디버깅하느라 시간을 낭비하는 경우가 많다.
  • WTP의 경우 eclipse 프로젝트를 주기적으로 배포하는 구조로 동작한다. 그런데 WTP 버그로 인해 소스 코드가 변경되었음에도 불구하고 소스 코드가 정상적으로 배포되지 않아 낭비하는 시간이 많다.
  • 가장 황당한 경우는 배포한 디렉토리가 삭제되는 경우이다. clean과 같은 작업으로 한번 디렉토리가 삭제될 경우 프로젝트를 정상적으로 배포하지 않아 테스트를 할 수 없는 경우이다. 이 경우 해결 방법을 찾기도 힘들다. 가장 많은 시간을 소비하는 경우이다.

위 3가지 경우만 하더라도 상당히 짜증나는 개발 환경인데 소스 코드를 배포하면서 발생하는 자잘한 버그들을 생각하면 좋은 개발 환경이 아니다. 이런 이유 때문에 eclipse에서 WTP 기반으로 개발하는 것을 썩 좋아하지 않는다. 그런데 이번 학기에 NEXT에서 수업을 하는데 딱히 대안이 없어 WTP를 사용했는데 학생들이 위와 같은 상황을 겪으면서 많은 시간을 낭비하는 것을 보니 다른 대안을 찾아야겠다는 생각이 들었다. 그래서 찾은 대안이 embedded tomcat을 사용하는 것이다. 다른 Web Application Server(이하 WAS)를 사용하는 경우는 모르겠지만 Apache Tomcat을 WAS로 사용하는 경우 embedded tomcat이 좋은 대안이 될 수 있다고 생각한다.

0개의 의견 from FB

7개의 의견 from SLiPP

2013-10-22 18:28

@eungju.park.1 나도 위키북 때의 경험이 너무 좋아서 jetty를 사용했었다. jetty 정말 가볍고 좋더라. 그런데 tomcat과 jetty가 미묘하게 차이가 있어서(커스텀 태그 설정에서 이슈가 있었던 듯하다.) 개발 서버가 tomcat인데 로컬 개발 환경이 jetty로 되어 있다 보니 tomcat 기능을 사용하지 못하는 경우가 있더라. 이 제한 때문에 삽질 좀 했지.

그래서 개발 서버나 실 서버로 tomcat을 사용하는 경우는 로컬 개발 환경도 tomcat으로 만드는 것도 삽질을 줄 일 수 있다는 생각이 들더라. 암튼 위키북 때의 embedded jetty 경험은 정말 좋았다는 생각이 든다.

그리고 그 때는 생각하지 못했는데 java application을 단축키로 재시작할 수 있도록 플러그인 설치하고 사용하니 정말 편하겠다고 생각한다. 소스 변경시 서버 재시작도 정말 좋은데 자바 소스 수정할 때마다 재시작하니까 것도 짜증나더라고... 암튼 이 아이디어는 너로부터 시작했지. ㅋㅋ

2013-10-23 08:59

http://blog.benelog.net/2879657 에 보면 local 개발 환경에서 WAS를 실행하는 여러가지 방법을 공유하고 있네요. wtp의 경우 external web module로 추가하고 사용하라는 이야기도 있는데 제가 테스트한 바라는 이 방식 보다는 embedded WAS 구조로 가는 것이 더 낫지 않을까라는 생각을 해봅니다. 둘 다 문제가 없는 방식이라면 개인의 취향 문제라는 생각이 드네요.

2013-10-23 09:31

페이스북에서 활동하고 계신 @정원희(https://www.facebook.com/AaronJung)) 님께서 external web module을 사용할 때의 설정 방법에 대해 자세하게 설명해 주어서 댓글에 추가합니다.


기본 프로젝트에는 소스와 그 외 xml/css/jsp 등을 적당히 src/main/webapp 밑에다가 두면 되고 lib/classes 의 경우에는

Eclipse 에서는 compile target 디렉토리를 webapp/WEB-INF/classes 로 해놓으면 에디터에서 파일 한두개만 바꾸었을 때 변경된 클래스만 알아서 컴파일되어 갱신되니 큰 문제가 없습니다. JSP파일은 그냥 변경해주면 변경하는 족족 알아서 컴파일되어 적용되구요 스프링의 XML의 변경 같은 경우에는 JRebel등을 통하지 않는 이상 어차피 스프링 프로젝트이면 재시작을 해줘야 하니까 뭘 쓰던 똑같을 거 같습니다.

classes/lib 안의 애들을 SVN이나 GIT으로 커밋하진 않구요, maven 프로젝트라면 빌드 후에 war:inplace 또는 war:exploded 를 해주면 src/main/webapp 아래 혹은 target/ 아래에 예쁘게 docBase로 설정할 수 있도록 경로를 만들어 줍니다.

보통 과정을 적어보자면

프로젝트 checkout 또는 import, 그 후 Maven 빌드 ( 필요한 다른 옵션과 함께 war:inplace 또는 war:exploded ), 이클립스의 컴파일 target 경로를 target 또는 webapp 밑의 WEB-INF/classes 경로로 지정, 이클립스에서 Servers에 tomcat 서버 만들고 module 에 Add External Web Module을 선택한 다음 프로젝트의 webapp를 docBase로 지정해주기. Auto reloading 은 보통 꺼주는데 그렇지 않으면 xml이나 class 파일 하나하나 건드릴때마다 이클립스가 내용이 변경되었으니 새로 띄우라고 (out of sync) 메세지를 보여줘서 그렇게 하고요.. 웹을 WTP 와 함께 디버그 모드로 띄우면 method signature가 바뀌든가 하지 않는 한 코드 수정한건 바이트코드 핫스왑으로 바로바로 코딩&확인이 가능하니까 편합니다.

2013-12-20 11:22

안녕하세요. Spring 4 출시기념으로 Spring 4 MVC를 임베디드 톰캣에서 돌아가는 프로젝트를 진행하고 있습니다. 이걸로 실무에 쓰려고 삽질중입니다. 기간이 정해져 있는지라 저도 열심히 되도록 노력하고 있습니다.

같이 Spring 4 와 임베디드 톰캣을 연구하고 발전하는 장이 됐으면 합니다. 오픈소스로 누구나 참여 가능합니다.

https://github.com/composite/spring4-mvc-embed-tomcat7-example

의견 추가하기