3.x 버전대의 스프링 프레임워크가 나온지 얼마 안된 것 같은데 벌써 4.1버전대가 릴리즈 됐다. 그래도 3.x 버전대까지는

종종 설정도 살펴보고 이것저것 시도해봤는데 프로젝트 때문에 한참을 못보다가 최근에 시간이 되서 바뀐건 없나 살펴보니

꽤 많이 바꼇다.. 예전 2.x버전대의 설정지옥에 비하면 요즘에는 많이 편해지긴 했지만 아직도 잘 돌아가게 설정 하려면 시간

깨나 잡아먹는 일이긴 하다. 그리고 설정이 간편해진 대신 구조가 복잡해서 모르고 복붙만 해서 쓰다보면 돌아가긴 하지만

잠재적인 위험을 가지고 있는 코딩을 할 수 있는 경우도 이번에 느꼈다. 보통 스프링 메이저 버전이 업그레이드 되면 한번씩

둘러보느라 이번에 최신버전으로 설치하고 테스트 해봤는데 설정에서 꽤 막혔다. 이 글에선 막혔던 부분과 해결 방법에 대해서

정리 해보려고 한다.

1. MyBatis, iBatis

스프링 4.x버전대 부터 iBatis의 지원이 전면 중단 되었다. 이전에 iBatis를 사용하던 프로젝트를 하던 분들은 아래와 같은

설정을 사용하면서 스프링 연동 라이브러리였던 ibatis-spring-xxxx와 함께 iBatis라이브러리를 사용하셨을 건데 4.x버전

에서 사용할 수 없으므로 삭제 하고 MyBatis라이브러리와 mybatis-spring-xxx 라이브러리를 받아서 import해줘야 한다.

* Spring 3.x대의 iBatis 설정 예


    

* Spring 4.x대의 MyBatis 설정 예

    
    
        
        
        
    
            	

변경된 점만 보려는 것이기 때문에 MyBatis설정은 따로 정리해보겠다. Mapper라는 개념이 새롭게 생기긴 했는데

마이그레이션을 생각하고 설정을 해보니 Mapper를 우선은 굳이 사용하지 않고 기존 메소드에서 변경된 메소드로

변경해주고 typeAliases같은 경우 따로 관리를 하므로 따로 config하는 xml로 빼고 쿼리 사용 방식등을 손보면

그나마 마이그레이션 범위가 많이 줄어들지 않을까 싶다. 물론 프로젝트에서 잘돌아가고 있는 iBatis를 MyBatis로

변경할 확률은 거의 제로라고 보지만.. 어쨋든 iBatis개발이 중단되고 MyBatis로 바뀐지 꽤 됐는데 이번엔 아예

지원이 중단되서 좀 섭하긴 하다.

2. Ajax를 통한 ResponseBody, RequestBody JSON처리

이제까지 스프링을 사용하면서 개인적으로 박수 백번 쳐주는 기능이다. RequestBody의 경우는 일반적인 DB 쿼리시

파라미터 전송시에 그냥 좀 편하네 정도 였지만 SAP연동시 Table Structure 파라미터를 보낼때는 정말 편리하다고

생각된다. Ajax로 처리할때는 아래와 비슷하게 하면 된다.

- JSP

var param = {};
var paramList = [];

for(var i=0; i<=10; i++){
      paramList.push({testdata : i});
}
param["list"] = paramList;

$.ajax({
      url : "getTestData.do"
     ,async : false
     ,type : "POST"
     ,dataType : "json"
     ,data : JSON.stringify(param)
     ,contentType: "application/json; charset=utf-8"			
     ,success : function(data){
        alert(JSON.stringify(data));
     }
});

- JAVA(Spring Bean)

                
@Autowired
private ObjectMapper objectMapper;

@RequestMapping(value = "/getData", method = RequestMethod.POST)	
public @ResponseBody Map getTestData(@RequestBody String httpParam, Model model) throws IOException, SQLException{
         Map paramMap = new HashMap();
         paramMap = objectMapper.readValue(httpParam, new TypeReference(){});

         List list = testService.getData(paramMap); 
         Map resultMap = new HashMap();
         resultMap.put("testDataList", list);
	
          return resultMap;
}

근데 3.0, 3.1~4.X 버전대의 ObjectMapper 설정이 조금씩 달라진다. JSON 처리를 위해 Message Converter로 많이 사용되는

것중에 Jackson 라이브러리가 있는데 일단 핸들러가 변경되었다. 아래 설정을 비교해 보겠다.

- 스프링 3.0.x

                
	
	
		
			
				
				
			
		
		
	
	

 

- 스프링 3.1~4.X

                
		 
	
        
            
            
                
                    
                        text/html;charset=UTF-8
                        application/json;charset=UTF-8
                    
                
                        
            
            	            	
            
        
                                
    

- 스프링 3.1~4.X (mvc:annotation-driven 사용시)

                
     
     	
            
                
                    
                        text/html;charset=UTF-8
                        application/json;charset=UTF-8
                    
                
                        
           
            	            	
            			
     		
             

3.0버전대에서 사용되던 AnnotationMethodHandlerAdapter가 3.1버전대에서 deprecate됐다. 그래도 사용가능하긴 하다.

그리고 위 설정에서 MappingJackson2HttpMessageConverter가 있는데 이는 Jackson 라이브러리가 2.x 버전에서 생겼고

1.x 버전에서는 MappingJacksonHttpMessageConverter가 사용된다.

Spring 4.x에서는 MappingJacksonHttpMessageConverter 또한 지원하지 않기 때문에 Jackson 2.x 버전대로 변경을

권장한다. 또한 ObjectMapper의 패키지도 변경되었으므로 기존 1.x 버전대의 Jackson 라이브러리를 사용하고 있었다면

패키지 명도 변경해줘야 한다. 그리고 MappingJackson2HttpMessageConverter의 경우 JSP에서 Ajax로 보낼때

(jQuery 기준) contentType: "application/json; charset=utf-8" 와 같이 명시해주지 않으면 RequestBody에서 파싱에

실패했다는 메시지가 뜰 것이다. 설정때문에 인터넷을 찾다보면 AnnotationMethodHandlerAdapter를 사용한 설정예가

주를 이뤄서 꽤 많이 찾아 다녔던 것 같다. 설정 변경부분만 살펴봤는데 역시 변화에 유연한 스프링이긴 해도 버전이

올라가면서 코어 마이그레이션 하기는 쉽지 않은듯 하다. 여담으로 이전에 3.0 버전대에서 보통 ResponseBody를 처리

할때 AnnotationMethodHandlerAdapter를 사용하면서 스프링 Model(org.springframework.ui.Model)를 리턴하는 방식을

사용했는데 변경된 방식을 사용해보니 Resolver를 타고 RequestMapping에 선언된 View 페이지로 계속 리턴이 되서

의아했다. 여러 글을 보다보니 mvc-annotation-driven을 사용해서 설정하거나 3.2이상 버전에서 권장되는

RequestMappingHandlerAdapter를 사용했을때의 처리 방식이 달라져서 이다.  처리 요청을 받았을때 스프링에서 인스턴스

들을 특정 order로 등록하게 되는데 컨트롤러의 메소드에서 리턴되는 값이 있을경우 RequestMappingHandlerAdapter의

getDefaultReturnValueHandlers() 에서 핸들러들을 검색하다가 supportsReturnType() 메소드를 통해 먼저 발견되는 경우

true를 리턴하게 되고 스프링의 Model을 핸들링하는 ModelMethodProcessor보다 ResponseBody를 관리하는

RequestResponseBodyMethodProcessor보다 우선순위가 상위이기 때문에 먼저 처리가 된것이고 (ResponseBody의

경우 MessageConverter를 통해 결과가 처리되므로 컨트롤러 메소드에서 리턴되는 결과와는 조금 별개로 볼 수 있다.)

이미 View Resolver는 설정에 추가된 상태이기 때문에 처리가 된 것으로 보인다. 좀 복잡해서 확실하게 이해되진 않았고

확실히 맞는지는 모르겠지만 대강은 윤곽이 잡히는 것 같다. 근데 DefaultAnnotationHandlerMapping을 사용했을시

스프링 Model을 ResponseBody로 리턴해도 정상적으로 처리된것은 아직 이해가 되질 않는다. deprecate된데에 뭔가

이유가 있지 않을까? 여튼  스프링이 버전업 될때마다 느끼는 거지만 이런 이해안되는 부분을 찾다보면 Java개발 패턴도

보게 되고 여러모로 공부가 된다. 다음 프로젝트는 이상한 Wrapper클래스로 떡칠해서 스프링 기능도 제대로 못써먹는 

이놈도 저놈도 아닌  모 프레임워크(egov 아님 ;) 환경 말고 스프링 기능을 접해볼 수 있는 프로젝트로 가보고 싶다.

설정변경 부분 보다 다른말이 더 길어지긴 했는데 이제 설정 부분은 코어 버전 바뀔때가 아니어도 가끔 확인해봐야될

필요가 있다 생각됐다. 글을 보시는 분들도 참고가 되셨으면 한다.

-- Syntax Highliter 처음 써보는데 글쓰기 힘드네요. 긁어가기 쉽게 글 쓰는 분들 감사합니다. ㅠㅠ

 

신고

보통 우리가 인터넷을 사용하면서 주소창에 흔히 볼수있는 주소 표현으로 다음과 같이..

 

http://xens.tistory.com/content/list.jsp?user=park&page=1 과 같은형태를 많이 보게 됩니다. 이를 RESTful 하게 표현하면

 

http://xens.tistory.com/content/list/user/park/page/1 과 같이 표현할 수 있게됩니다. 개념상으로는 단순히 이렇게 주소

 

표기를 위해서 뜬금없이 나타난 것은 아니고 'URI로 자원대상을 명시하고 Method로 자원에대한 행위를 정의한다'

 

를 베이스로 가지고 있는 아키텍쳐 이며 기본적으로 CRUD(Create, Read, Update, Delete)와 매치될수 있는 형태의 서비스

 

에서 쓰이고 있습니다. 저도 여기저기서 글만 봤지 최근에서야 공부겸 예제를 작성해 봤는데 글 제목에서 썼듯 URL Mapping

 

문제로 굉장한 삽질을 했습니다. 분명 시간이 지나면 잊어버릴게 뻔하니 간단히 정리를 해봅니다.

 

예제를 만들때는 Spring Framework 3.0.5와 Tomcat 7, jQuery를 사용했습니다. 이클립스에서 프로젝트 구조는 다음과

 

같다고 보시면 됩니다.

 

 

 

 

※JSP 호출 오류 해결방법

  REST형식으로 호출하면서 처음부터 진입을 가로막는것이 JSP 입니다. 처음 시작페이지가 content.jsp라고 하겠습니다.

 

 요즘에는 보통 서비스(URL)호출시 AJAX를 사용하여 콜백으로 온 데이터를 통해 결과를 출력하거나 하는 개발 방식을 많이

 

 사용하고 있는데 예를 들어서 content.jsp 에서 아래와 같이 호출한다고 가정합니다(처음 실행페이지가 content.jsp).

 

 $.ajax({

   ...

   url : "/person/parkdi"

   ...

 });

 

 그리고 스프링 컨트롤러는 다음과 같이 작성 했다고 가정합니다.

 

 @RequestMapping(value="/person/{id}", method=RequestMethod.GET)
 public ModelAndView getDataRestfulUrlPattern(@PathVariable("id") String id){...}

 

 이렇게 작성하고 바로 호출을 해보면 호출하는 content.jsp 자체가 에러가 납니다. 일단 이상현상을 보게된 후

 

 제일 먼저 봐야할것은 WAS의 web.xml 파일입니다. 우리는 Spring Framework를 사용했기 때문에 DispatcherServlet를

 

 다음과 비슷하게 매핑시켜줬을 겁니다.

 

  <servlet>
    <servlet-name>dispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
      <param-name>ContextConfigLocation</param-name>
      <param-value>/WEB-INF/webmvc_config.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>*.do</url-pattern>
  </servlet-mapping>

 

실행할때의 톰캣의 Console로그를 보시면 content.jsp파일도 DispatcherServlet에서 처리하려고 하는것을 볼수 있습니다.

 

그러나 위의 web.xml 설정과 같이 *.do에 대한 패턴을 매핑하도록 했기 때문에 content.jsp에 대한 매핑 URL을 찾을수가

 

없어서 에러가 발생하게 됩니다. 우선 문제에 대한 해결책은.. web.xml을 수정해야 합니다.

 

  <servlet>
    <servlet-name>dispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
      <param-name>ContextConfigLocation</param-name>
      <param-value>/WEB-INF/webmvc_config.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>/</url-pattern>
  </servlet-mapping>
  <servlet-mapping> 
    <servlet-name>default</servlet-name>
    <url-pattern>*.js</url-pattern>
    <url-pattern>*.css</url-pattern>
    <url-pattern>*.jpg</url-pattern>
    <url-pattern>*.gif</url-pattern>
    <url-pattern>*.png</url-pattern>
    <url-pattern>*.ico</url-pattern>
    <url-pattern>*.swf</url-pattern>
 </servlet-mapping>       

 

우선 문제에 대한 해결책은 위의 붉은 글씨처럼 Dispatcher서블릿의 url-pattern을 '/' 로 변경하고 deault servlet의 url-pattern

 

을 추가해줬습니다. 호출하는 페이지인 content.jsp에서는..

 

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

 $.ajax({

   ...

   url : "<c:url value='/person/parkdi' />"    //컨텍스트Path(spring_webmvc_restful_ex1/person/parkdi)

   ...

 });

 

컨트롤러에서는 위에 작성된 예와 같이 그대로 두고 호출하면 됩니다. 일단 문제는 해결됐지만 이유는 알아야 되겠죠.

 

※오류 원인

 

JSP는 WAS(톰캣 등)의 서블릿 컨테이너에서 처리를 하게 됩니다. 톰캣을 예로 보면 이클립스 프로젝트에서의 web.xml이 아닌

 

%CATALINA_HOME%(톰캣 설치 디렉토리)의 conf/web.xml을 열어보면

 

 <sevlet-mapping>

  <servlet-name>jsp</servlet-name>

  <url-pattern>*.jsp</url-pattern>

 </sevlet-mapping>

 <servlet>
    <servlet-name>jsp</servlet-name>
    <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
    <init-param>
       <param-name>fork</param-name>
        <param-value>false</param-value>
    </init-param>
    <init-param>
        <param-name>xpoweredBy</param-name>
        <param-value>false</param-value>
     </init-param>
    <load-on-startup>3</load-on-startup>
  </servlet>

 

위와같이 org.apache.jasper.servlet.JspServlet 에서 jsp를 처리한다는 것을 볼 수 있습니다. JSP 인식오류 해결을 위해

 

위에서 추가했던 <servlet-name>default</servlet> 의 경우 서블릿 컨테이너의 DefaultServlet을 의미하는데 

 

url-pattern을 '/'로 정의한 경우에 디폴트 서블릿을 의미하며 이 디폴트 서블릿은 서블릿 매핑 URL에 걸리지 않는 요청을

 

처리한다고(톰캣 설정파일의 주석) 되어있습니다. 그래서 이제 DispatcherServlet의 url-pattern을 '/'로 설정함으로서

 

JSPServlet의 JSP처리와 DispatcherServlet의 처리를 분리 시켰습니다. 이렇게 분리 할경우 JSP와 스프링 컨트롤러 매핑은

 

잘 처리되지만 css, js등의 정적 컨텐츠들이 나오지 않는것을 볼수 있습니다. 이는 DispatcherServlet의 url-pattern을 '/'로

 

설정하면서 톰캣의 server.xml에 정의되있는 DefaultServlet의 url-pattern을 무시하게 되기 때문에 DefaultServlet이 작동하지

 

않게 되기 때문입니다. 따라서 호출시 정적 컨텐츠들도 DispatcherServlet이 처리하게 되니 표현되지 않게 됩니다.

 

<servlet-mapping> 
  <servlet-name>default</servlet-name>
  <url-pattern>*.js</url-pattern>
  <url-pattern>*.css</url-pattern>
  <url-pattern>*.jpg</url-pattern>
  <url-pattern>*.gif</url-pattern>
  <url-pattern>*.png</url-pattern>
  <url-pattern>*.ico</url-pattern>
  <url-pattern>*.swf</url-pattern>

</servlet-mapping> 

그래서 DefaultServlet이 처리할 url-pattern을 재정의 해준것이 윗 부분입니다. 사실 위와 같이 정의해줄경우 정적 컨텐츠에

 

대한 url-pattern을 전부다 정의해줘야 줘야하므로 지저분하기도 합니다. 그래서 스프링 3.0에서는 이 부분을

 

<mvc:default-servlet-handler /> 를 선언해줘서 해결을 한다고 합니다. 여기에는 주요 WAS의 DefaultServlet 명에

 

대한 내용을 처리하도록 되있다고 하네요. 저도 위의 DefaultServlet의 매핑을 재정의 해주기 전에 발견해서 적용해봤는데

 

xmlns:mvc="http://www.springframework.org/schema/mvc ,

xsi:schemaLocation=http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-3.0.xsd

 

<bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping" p:alwaysUseFullPath="true" />

 

위 내용이 분명히 선언되있는데도 아래와 같이

 

org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'mvc:default-servlet-handler'.

 

찾을수 없다고 계속 떠서 포기했습니다. 찾아봐도 위 내용의 XML확인이나 <mvc:annotation-driven /> 추가 여부만

 

확인하라는 답변밖에 없더군요.. 혹시 비슷한 경험 있으신 분은 답변 주시면 감사하겠습니다. 어쨋든 그냥 REST의 개념만

 

정리하고 CRUD에 해당하는 스프링의 RequestMethod(POST,GET,PUT,DELETE)를 좀 더 알아보려고 했던 것인데

 

하루종일 삽질만 한 것 같습니다;;

신고