1. SpringFramework기반 프로젝트 중 우연치 않게 발견한 내용입니다.

공통 기능을 jar로 배포하고 확장기능만 개발하는 형태로 되어 있는 프로젝트를 운영서버에 배포를 했으나 Mapper Interface BindingExceptin이 발생하고 해당 Interface가 not Known 으로 나오는 현상이 발생한겁니다.

 

해당 프로젝트를 개발자 eclipse에서 실행하면 아무 이상없이 정상적으로 실행되는데, 운영서버에 배포만 하면 동일한 오류가 발생하는 것입니다.

 

결론은 개발자 한명이 해당 mapper Interface package를 생성하고 이곳에 Mybatis query xml을 위치시킨것입니다.

해당 package는 jar에서 사용하는 동일한 package이고 권장하지 않는 사용법이었습니다.

이를 바로잡는다고 해당 패키지 밑에 있는 xml은 WE-INF/sqlmap/ 이하로 옮기는 migration 시킨것입니다.

그러면서 정상 package는 삭제하지 않은것입니다.

 

xml 에 설정된 component-scan 에의해 해당 패키지를 scan한것입니다.

 

여기서 왜 eclipse에서는 정상작동했는데, 운영서버에서는 오류를 냈느냐는 것입니다.

차이는 class파일 loading순서에 따른 것이었습니다.

 

eclipse는 class loading 순서를 임의로 조정할수 있지만 실제 운영환경에서는 was에서 지정하는 순서에 의해 Loading된것입니다.

즉, 운영환경 WAS 기반하에서는 jar 파일에 있는 class보다 WEB-INF/classes 이하에 위치한 class파일을 우선시 하는데 비해

eclipse는 Project 설정에서 Java Build Path ==> Order and Export 탭에서 이를 자유롭게 조정할수 있는 것입니다.

 

추가 확인 및 연구사항

 

1. 좀더 세밀하게 접근하면 이후부터는 ClassLoader를 이해해야 합니다.

이부분에 대해서는 별도 구글링을 통해 알아보면 도움이 될듯 합니다.

 

2. 그리고 또하나 패키지만 선언해놓고 class 파일을 만들지 않은 경우에 eclipse가 이를 어떻게 처리하는지 확인해 봐야할 듯합니다.

  운영서버 war로 export 하게 되면 빈 패키지도 classes 이하에 그대로 생성되기 때문에 ClassLoader가 이를 로딩해버립니다.

 

Spring component-scan도 이 class loader에 의한 것이라 여겨지기에 비슷하게 작동한듯 합니다.

(이부분 조금더 정확하게 확인 필요)

 

 



Spring 에서 RESTful을 지원하면서 사용빈도가 높아진(개인적인 견해)  @PathVariable Annotation이 사용에 있어서 주의할 점이 있습니다.

 

일반적으로 다음과 같이 사용을 합니다.

 

@RequestMapping(value = "/test/{aaa}/{bbb}", method = RequestMethod.GET)
 public String homeTest(Locale locale, Model model, @PathVariable String aaa,@PathVariable String bbb) {
  
  logger.info("Welcome home! The client locale is {} {}.", aaa, bbb);
  ... 중략 ... 
  return "home";
 }

 

 

위의 코드는 일반적으로는 오류없이 실행이 됩니다.

하지만 다음과 같이 이클립스의 컴파일러 옵션을 변경한 상태에서 컴파일 & 실행을 하게 될 경우 다음과 같은 오류가 발생합니다.

 

 

디폴트는 위의 체크박스가 모두 체크되어 있는 상태입니다.

 

오류내용은 다음과 같습니다. 결과적으로 해당 URL을 인식하지 못합니다. 때문에 해당 클래스의 메소드까지 전달되지도 못하는 상태라 디버그도 찍히지 않습니다.

 

 

 

차이점은 뭘까요?

 

@PathVariable을 사용하는 데 있어서의 차이점입니다.

위와 같은 옵션에서도 오류가 없게 하려면 다음과 같이 사용을 해야합니다.

 

@RequestMapping(value = "/test/{aaa}/{bbb}", method = RequestMethod.GET)
 public String homeTest(Locale locale, Model model, @PathVariable("aaa") String abcd,@PathVariable("bbb") String bcd) {
  
  logger.info("Welcome home! The client locale is {} {}.", abcd, bcd);
  ... 중략 ... 
  return "home";
 }

 

 

경우에 따라서 서버의 컴파일러 옵션이 디버깅을 지원하지 않은 상태일때를 만날 수 가 있는데, 이런 경우를 피하기 위해서는 가급적 위와 같은 형태로 @PathVariable을 사용하길 권장합니다.

 

SpringFramework 공식사이트인 springsource.org 에서도 다음과 같은 내용을 확인할 수 있습니다.

 

"Or if the URI template variable name matches the method argument name you can omit that detail. As long as your code is not compiled without debugging information, Spring MVC will match the method argument name to the URI template variable name:"

 

자세한 내용 :  springsource.org

 

 

추가.

실제 관련 프로젝트 중 IBM AIX 서버에서 ant build(ibm java 1.6)후 WebSphere 에서 실행하는데, 모든 기능이 정상임에도 불구하고 위와 관련된 내용만 오류가 발생하는 사례가 있었습니다. 물론 권장내용대로 수정 후 오류는 없어졌습니다. 

 

혹시 개발PC에서는 잘 되는데, 서버로 가져가면 안되는 경우가 발생한다면 이부분을 확인하시기 바랍니다.

 

 



Spring에서 Custom Error Page를 만들어 테스트 하는데, Chrome에서는 정상적으로 표시가 되는데, IE에서만 나오지 않아서 찾아봤습니다.

 

이유는 Custom Error Page 크기가 너무 작아서라는 군요.

 

 

Custom error page 의 최소 크기는 다음과 같습니다.

 

* 512Bytes이상이어야 하는 페이지

 

400 Bad Request

404 Not Found

406 Not Acceptable
408 Request Time-out
409 Conflict
500 Internal Server Error
501 Not Implemented
505 HTTP Version Not Supported

 

 

* 256Bytes 이상이어야 하는 페이지

 

403 Forbidden

405 Method Not Allowed
410 Gone

 

다음은 Wikipedia에 나온 Custom error page에 대한 내용입니다.

 

Web servers can typically be configured to display a customised 404 error page, including a more natural description, the parent site's branding, and sometimes a site map, a search form or 404 page widget. The protocol level phrase, which is hidden from the user, is rarely customized.

Internet Explorer, however, will not display custom pages unless they are larger than 512 bytes, opting instead to display a "friendly" error page.[3] Google Chrome includes similar functionality, where the 404 is replaced with alternative suggestions generated by Google algorithms, if the page is under 512 bytes in size.[citation needed]. This is a violation of RFC 2616, which states that "user agents SHOULD display any included entity to the user".

Another problem is that if the page does not provide a favicon, and a separate custom 404 page exists, extra traffic and longer loading times will be generated.[4][5]



« PREV : 1 : 2 : 3 : 4 : 5 : 6 : ··· : 11 : NEXT »