구글 SMTP를 사용하다가, 고객의 요구에 따라 네이버나 다음으로 변경하려고 했는데...
smtp 로 메일 발송테스트를 하는데 포트만 바꾸면 될 줄 알았더니... 아니더라.
상당한 삽질을 통해 확인한 결과는 다음과 같다.

application.properties

mail.host = smtp.gmail.com
mail.port = 587
mail.protocol = smtp

mailService 빈설정

<bean class="...MailServiceImpl">
        <constructor-arg name="mailSender">
            <bean class="org.springframework.mail.javamail.JavaMailSenderImpl"
                  p:password="${mail.password}"
                  p:host="${mail.host}"
                  p:port="${mail.port}"
                  p:protocol="${mail.protocol}"
                  p:username="${mail.username}"
                  p:defaultEncoding="${mail.encoding}">
                <property name="javaMailProperties">
                    <props>
                        <prop key="mail.smtp.starttls.enable">${mail.smtp.starttls.enable}</prop>
                        <prop key="mail.smtp.auth">${mail.smtp.auth}</prop>
                    </props>
                </property>
            </bean>
        </constructor-arg>
    </bean>

네이버 메일 테스트 시

mail.xml 파일의 MailServiceImpl 빈 설정을

<bean class="...impl.MailServiceImpl">
    <constructor-arg name="mailSender">
        <bean class="org.springframework.mail.javamail.JavaMailSenderImpl"
            p:password="${mail.password}" p:host="${mail.host}" p:port="${mail.port}"
            p:protocol="${mail.protocol}" p:username="${mail.username}"
            p:defaultEncoding="${mail.encoding}">
            <property name="javaMailProperties">
                <props>
                    <prop key="mail.smtp.starttls.enable">${mail.smtp.starttls.enable}</prop>
                    <prop key="mail.smtp.auth">${mail.smtp.auth}</prop>
                    <prop key="mail.smtps.ssl.checkserveridentity">true</prop>
                    <prop key="mail.smtps.ssl.trust">*</prop>
                </props>
            </property>
        </bean>
    </constructor-arg>
</bean>

의 형태로 변경한다. 기존 설정내용과의 차이는

<prop key="mail.smtps.ssl.checkserveridentity">true</prop>
<prop key="mail.smtps.ssl.trust">*</prop>

그리고 application.properties의 내용을 다음과 같이 변경한다.

mail.host = smtp.naver.com
mail.port = 465
mail.protocol = smtps

테스트를 위해서 작성된 MailServiceImplTest를 실행하여 확인하다.
테스트를 실행하기 위해서는 MailServiceImplTest-context.xml 의 내용을 다음과 같이 변경하시고,

<bean class="...MailServiceImpl">
    <constructor-arg name="mailSender">
        <bean class="org.springframework.mail.javamail.JavaMailSenderImpl"
            p:password="${mail.password}" p:host="${mail.host}" p:port="${mail.port}"
            p:protocol="${mail.protocol}" p:username="${mail.username}"
            p:defaultEncoding="${mail.encoding}">
            <property name="javaMailProperties">
                <props>
                    <prop key="mail.smtp.starttls.enable">${mail.smtp.starttls.enable}</prop>
                    <prop key="mail.smtp.auth">${mail.smtp.auth}</prop>
                    <prop key="mail.debug">true</prop> <!-- 이건 테스트를 위한 디버그 내용 확인을 위한 겁니다.  -->
                    <prop key="mail.smtps.ssl.checkserveridentity">true</prop>
                    <prop key="mail.smtps.ssl.trust">*</prop>
                </props>
            </property>
        </bean>
    </constructor-arg>
</bean>

test의 setFrom의 메일 계정은 로그인에 사용된 계정과 동일하게 변경한다.


다음 메일 SMTP 테스트 시

daum으로 발송할 경우에는, MailServiceImplTest 를 다음과 같이 변경하고

<bean class="...MailServiceImpl">
    <constructor-arg name="mailSender">
        <bean class="org.springframework.mail.javamail.JavaMailSenderImpl"
            p:password="${mail.password}" p:host="${mail.host}" p:port="${mail.port}"
            p:protocol="${mail.protocol}" p:username="${mail.username}"
            p:defaultEncoding="${mail.encoding}">
            <property name="javaMailProperties">
                <props>
                    <prop key="mail.smtp.starttls.enable">${mail.smtp.starttls.enable}</prop>
                    <prop key="mail.smtp.auth">${mail.smtp.auth}</prop>
                    <prop key="mail.debug">true</prop> <!-- 이건 테스트를 위한 디버그 내용 확인을 위한 겁니다.  -->
                </props>
            </property>
        </bean>
    </constructor-arg>
</bean>

application.properties

mail.host = smtp.daum.net
mail.port = 465
mail.protocol = smtps

메일을 발송할 때에는, from 이메일 주소는 로그인에 사용된 메일주소와 동일해야 한다. protocol이 smtp가 아니라 smtps 이다. JavaMail에서 접근방식이 다를 줄은 몰랐다.

protocol이 'smtps'여야 SSL 설정이 활성화된다.

별도의 설정 프로퍼티가 있을 줄 알았는데... 크흐.


요즘 많이 사용되는 AOP Logging. 현재 작업 중인 프로젝트에서도 사용중인데, 최근 기능을 추가하면서 문제가 발생했다.


● 문제발생

현재 사용중인 프로젝트에서도 AspectLogging 기법을 사용했다. 그런데, class cast를 하는 과정에서 지속적으로

Exception in thread "main" java.lang.ClassCastException: $Proxy11 cannot be cast to classA

라고 하는 문제가 발생하면서 로깅클래스에서 동작이 멈추는 증상이 나타났다. 물론…
AOP측에서 이에 대한 예외처리를 제대로 했으면 별문제가 없었겠지만,


● 문제요인

문제가 발생하는 부분을 유심히 살펴봤다. 스프링의 ReloadableResourceBundleMessageSource를 확장extends하여 간단한 메소드를 추가한 ResourceBundleMessageSource클래스로 class casting을 하는 부분에서 문제가 발생하고 있었다.


● 힌트

이 문제가 왜 생겼는지 인터넷 검색에 들어간다.

그러다가 발견한 힌트!

classcastexception-proxy-cannot-be-cast-to-using-aop - Stackoverflow

제일 마지막 부분에

a good article about proxy creation in Spring

이 글을 보고 깨달음을 얻었다.


● 해결책

  1. BundleMessageSource 라고 하는 인터페이스를 만들고, ResourceBundleMessageSource 클래스에서 implements 로 구현한다고 선언.
  2. ResourceBundleMessageSource 를 class casting 하는 부분을 BundleMessageSource 로 변경하였다.
  3. OK~!

● 정리

… proxy에서 효과적인 캐스팅 방식은, ‘클래스 캐스팅을 사용할 경우 인터페이스를 선언하여 구현하고 인터페이스로 캐스팅하는 것’ 이다.

얼마 전에 JSON을 사용해서 AJAX 통신 API를 만드는 과정에서 삽질을 한 적이 있다. 기본만 제대로 살폈으면 쉽게 넘어갈 수 있는 일이었는데 나의 얼렁뚱땅 대충대충 ‘필요하면 그때그때 찾아서 쓰면 되지 뭐.’ 라는 안일함이 하루의 시간을 날려먹는 상황을 낳고 말았다. 방법은 정말 간단했다.

헤맸던 소스: Before Source

  • ● TestForm.java

    @Data
    @NoArgsConstructor
    @ToString
    public class TestForm {
      private String id;
      private String name;
      private List<TestTag> testTags;
    
      @Data
      @NoArgsConstructor
      @ToString
      public class TestTag {
          private String id;
          private String tag;
      }
    }
    
  • ● TestController.java

    @Controller
    public class TestController {
      private static final Logger logger = LoggerFactory.getLogger(TestController.class);
    
      @RequestMapping(value="/test", method=RequestMethod.GET)
      public void test(@RequestBody TestForm form, ModelMap map) {
          logger.debug("TestForm : {}", form);
      }
    }
    
  • ● Form JSON

      var form = {
          id: "123",
          name: "123",
          testTags: [{id: "1111", tag: "2222"}]
      };
    
      $.ajax({
          url: "http://localhost:8080/test",
          method: "get",
          type: "json",
          data: form,
          success: function(data) {
              console.log(data);
          }
      });
    

    여러가지 시도를 해봤지만, form의 데이터를 TestController의 test에서 제대로 받아들이지 못하는 문제로 골머리를 썩었다(지금 생각해보면 나의 무식함에 부끄럽지만).

해결 코드: After Source

  • ● TestForm.java

    @Data
    @NoArgsConstructor
    @ToString
    public class TestForm {
      private String id;
      private String name;
      private List<TestTag> testTags;
    
      @Data
      @NoArgsConstructor
      @ToString
      public static class TestTag {
          private String id;
          private String tag;
      }
    }
    
  • ● TestController.java

    @Controller
    public class TestController {
      private static final Logger logger = LoggerFactory.getLogger(TestController.class);
    
      @RequestMapping(value="/test", method=RequestMethod.POST)
      public void test(@RequestBody TestForm form, ModelMap map) {
          logger.debug("TestForm : {}", form);
      }
    }
    
  • ● Form JSON

      var form = {
          id: "123",
          name: "123",
          testTags: [{id: "1111", tag: "2222"}]
      };
    
      $.ajax({
          url: "http://localhost:8080/test",
          method: "post",
          type: "json",
          contentType: "application/json",
          data: JSON.stringify(form),
          success: function(data) {
              console.log(data);
          }
      });
    

Before Source와 After Source의 차이를 눈치챘는가? ㅡ_-)?
RequestMethod가 GET에서 POST로 변경되었다. 이에 대한 설명을 해본다. 토비의 스프링에 @RequestBody, @ResponseBody 를 살펴보기 바란다.

@RequestBody, @ResponseBody

최근 개발하고 있는 방식은 대부분이 프론트엔드와 백엔드를 분리하여 개발을 하고 있다. 프론트엔드의 AJAX요청은 대부분 JSON으로 되어 있고, 이에 맞춰 백엔드에서도 JSON 형태로 응답을 해주는 방식을 취하게 된다. 스프링에서는 이와 관련된 @MVC 관련 애노테이션과 설정을 통해 기능을 제공하고 있다.

  • ● @RequestBody

    이 애노테이션이 붙은 파라미터에는 HTTP 요청의 본문body 부분이 그대로 전달된다.
    AnnotationMethodHandlerAdapter에는 HttpMessageConverter 타입의 메시지 변환기message converter가 여러 개 등록되어 있다. @RequestBody가 붙은 파라미터가 있으면 HTTP 요청의 미디어 타입과 파라미터의 타입을 먼저 확인한다(servlet-context.xml 에서 <annotation-drvien> 태그 내에 선언하는 <message-converter> 에서 확인). 메시지 변환기 중에서 해당 미디어 타입과 파라미터 타입을 처리할 수 있다면, HTTP 요청의 본문 부분을 통째로 변환해서 지정된 메소드 파라미터로 전달해준다.

    내가 헤매던 부분이 바로 이부분이었다. ㅡ_-);;JSON 메시지 변환기에는 MappingJackson2HttpMessageConverter를 사용했다. @RequestBody 애노테이션은 요청에서 Body부분을 살펴 요청된 데이터를 추출하여 파라미터로 변환해주는데, ‘GET’ 메소드 요청의 경우에는 HTTP Body에 요청이 전달되는 것이 아니라, URL의 파라메터로 전달(ex: http://localhost:8080/test?id=123&name=123&testTag=…) 형식으로 전달되기 때문에 @RequestBody로 받으려고 해도 서로 다른 곳을 보며 데이터가 없다는 결과를 던질 수밖에 없다(이 부분도 로그에 대해서 상세하게 설정해서 살펴보면서 확인한 결과. 로그! 개발 중에 문제가 되는 요인들을 찾기 위해서 관심을 가지자).

  • ● @ResponseBody

    @ResponseBody는 @RequestBody와 비슷한 방식으로 동작한다. @ResponseBody가 메소드 레벨에서 부여되면 메소드가 리턴하는 오브젝트는 뷰를 통해 결과를 만들어내는 모델로 사용하는 대신, 메시지 컨버터를 통해 바로 HTTP 응답의 메시지 본문으로 변환된다.

    간단히 이야기 하자면, 요청한 형태에 맞춰서 메시지 변환기를 통해 결과값을 반환한다. ‘콩심은 데 콩나고 팥 심은데 팥난다.’ 랄까? ContentNegotiatingViewResolver 와는 동작방식이 좀 다르다. ContentNegotiatingViewResolver는 등록되어 있는 ViewResolver중에서 controller 메소드의 리턴값을 통해 등록된 ViewResolver 중에서 적합한 형태로 처리해서 반환하는 반면, @ResponseBody는 @RequestBody가 선택한 형식으로 결과값을 변환하여 반환한다고 보면 된다.

  • ● MessageConverter 메시지 변환기의 종류는 Spring API 문서를 참고하자.

정리

해당하는 애노테이션들이 어떻게 동작하는지 내가 했던 인터넷 설정들이 어떻게 반응하는지를 제대로 이해했다면, 별다른 삽질없이 조용히 넘어갈 수 있던 문제였는데, 쉬운 문제였다. 하아!!
요즘 들어서 부쩍 ‘기본을 탄탄히 갖춰야겠다.’라는 생각을 하게되는 일들이 많아지고 있다.

끊임없이 공부하고 공부하라!

  • ● 이와 관련된 내용들은 ‘[토비의 스프링]에서 [스프링 @MVC]’ 관련 내용을 상세하게 설명되어 있다.



NHN 그린팩토리 주변에 보면 고급 아파트들이 둘러쳐져 있다. 

  처음으로 와본 그린 팩토리. 2층과 1층은 일반인에게 개방되어 있기에 인근 주민들이 찾아와 시간을 보내는 모습이 색다르다. 하지만, 이 주민들 중 누군가는 그린팩토리의 창으로 비치는 태양이 눈부시다고 넣은 민원에 서명을 한 이도 있지 않을까? ㅋㅋ


  접수창구에는 올드멤버중 한분이신 채수원님이 주말알바로 접수요원을 하고 계셨다. 오랜만에 뵙기에 반갑게 인사드리고 약간의 기념품(스티커, 배지, 군것질류, 생수)을 챙기며 커넥트 홀로 들어섰다.




  앞자리로 이동하니, 첫발표자인 정상혁님과 다다음 발표자인 백기선님을 뵐 수 있었다.




  정상혁님은 '[Spring 3.0 -> 3.1 -> 3.2 따라하기]'라는 주제로 발표를 시작하신다. 소스코드가 많은 발표이기에 github 에 마크다운으로 작성된 문서를 기반으로 발표를 진행하신다. 이런 방법도 괜찮다 싶다. 개발과 관련된 발표자료를 만들때 소스코드를 이쁘게 표현하기가 참 쉽지 않은데, 그럴바에는 차라리 마크다운 문서로 보여주고 이를 공요하는 것이 적절해보인다. 프리젠테이션 파일로 만들어진 발표자료는 나중에 보기가 쉽지 않고, 시스템에서 텍스트 검색도 되지 않아서 나중에 다시볼 가능성이 극히 희박하다.


  스프링의 버전이 3.0에서 3.1로 넘어가면서 많은 변화가 일어났다. 스프링이 하위호환성(새로 출시된 프레임워크가 이전 프레임워크에 맞춰 개발된 기능을 그대로 유지-지원하는 것)을 강조하는 프레임워크지만, 코드의 개선을 위해서 3.1에서는 꽤 많은 부분이 변경되었다. 이 변경된 항목들에 대해서 찬찬히 짚어가는 시간이 지속되었다. 여전히 스프링 3.0을 이용하고 있는 프로젝트가 많은 상황에서 스프링 3.1 이상으로 업그레이드를 하려고 하는 이들에게 도움이 되었으리라고 본다.


  다음 발표는, 성능테스트 툴로 사람들의 많은 관심을 받고 있는 nGrinder에 관한 발표였다. 'nGrinder 초딩도 하는 성능 테스트'라는 제목으로 윤준호님이 발표하셨다. 낼모레 불혹을 앞두고 있는 '디자이너 출신'의 개발자는 nGrinder의 미려함에 대해서 강조하셨다.

  창조자인 개발자에게 자신의 창조물을 파괴하는 행위인 '테스트'는 참 힘든 일이다. 하지만, 자신이 만든 창조물의 성능과 안정성을 높이는 일은 외면해서는 안될 일이다. 어느 개발자들은 '테스트'는 품질관리QA(Quility Assurance)자에 의해서 진행이 되어야 한다고 말하지만, 나는 개발자가 일정수준 이상의 품질을 갖춘 제품을 만들어낼 의무가 있다고 본다.

  개발자가 일정수준 이상의 품질을 갖춘 제품을 만들어내기 위해서는 '테스트'를 진행해야 하는데, 그 테스트를 개발자 스스로 하게 하려면 어떻게 해야할까? '테스트'가 쉬워야 한다. 쉬워야 테스트를 쉽게 하고 제품의 품질을 높이면 자랑할 수가 있다. 테스트를 하면할수록 성능이 개선된다면 개발자는 자발적으로 테스트를 수행하게 될 것이다.


  nGrinder는 Grinder에서 시작되었다. Java 이외의 Jython과 Groovy를 지원하며, 테스트에 사용되는 스크립트를 자동생성하고 자체 SVN으로 관리해주고 테스트 결과를 저장하여 살펴볼 수 있는 기능을 제공한다. IDE와 클러스터링을 지원하면서 개발자의 '제품'에 대한 성능 테스트를 용이하게 한다. 이렇게 테스트를 용이하게 하면서 NHN내부에서도 620여명의 사용자가 11,000건의 테스트를 진행하며 성능 테스트 활동이 10배이상 증가하는 테스트를 달성했다고 한다.

  내가 만든 제품에 대해서도 성능테스트를 진행해봐야겠어. ㅡ_-);;


  세번째 발표는, whiteship 이라는 닉네임으로 '스프링 프레임워크'와 관련해서 잘 알려진 백기선님이 'Vert.x와 socket.io 이해 및 활용'이라는 주제로 발표하셨다. 특이하게, 자신의 큰 딸 '서연이'와 함께하는 발표였다. 발표 중간중간에 서연이의 돌발 행동에 참석자들은 흐뭇한 '아빠미소'를 짓고 있지 않았을까?



  시작에 '왕좌의 게임'에 나오는 말을 인용하며 '개발이 딸보다 쉬웠다' 라는 그의 말을 조금은 이해할 수 있는 순간이었달까?

Vert.x는 매우 쉽게 확장 가능한 차세대 비동기 애플리케이션 개발 플랫폼이다.

  Vert.x는 자바스크립트 엔진을 이용한 node.js와 비교되는 Java를 기반으로 하는 비동기 애플리케이션 개발 플랫폼이다. 백기선님은 Vert.x에 관심을 가지고 관련한 글을 꾸준하게 작성하고 있다. 지금도 꾸준하게 관련한 소식들을 게재하고 있다.

  Vert.x의 핵심요소는 Netty(IO 처리), Hazelcast(메모리형 데이터를 분산처리할 수 있는 그리스 시스템 제공)이다.

  Vert.x 의 주요 개념으로 Verticle, Vert.x. instance, Ployglot, Concurrency 에 대해서 하나하나 짚어나간다.

  Verticle은 Vert.x 에서 배포가능한 애플리케이션 단위이며 개별적인 클래스로더를 사용하여 실행해주며, 손쉽게 클러스터링할 수 있다. 수평적인 확장을 지원하며, 확장된 Verticle 간에는 메시지를 주고 받을 수 있다.

  Polyglot은 JVM에서 실행가능한 다양한 언어들로 작성할 수 있다.JavaScript, Ruby, Java, and Groovy 등의 언어를 지원하고 있으며 추가적으로 Clojure, Scala and Python 등의 다양한 언어를 지원할 것으로 보인다.

  Vert.x 를 이용할 때는 vertx-core, vertx-platform을 이용하면 된다. 버전업 되면서 사용하는 방법이 달라졌다고 한다. 라이브코딩을 하다가 당황하셨지만 능숙하게 대처하는 모습에서 그의 발표경험의 연륜을 짐작하게 만든다.



  node.js가 많은 인기를 끌게 만든 모듈 중 하나가 socket.io(전송 방식을 추상화하여 모든 브라우저와 모바일 기기용 실시간 애플리케이션을 개발가능하도록 하는 것이 목적)다. Socket.io를 이용해서 실시간 웹 기술을 이용하여 요즘 많이 관심받는 푸쉬Push 기술을 구현하기가 용이해진다. Socket.io 는 node.js의 모듈이다보니 자바쪽에서 아쉬워하는 녀석 중에 하나였는데, 기선님이 keesun/mod-socket-io 를 만들어내어 오픈소스로 제공하고 있다.

  스프링 4.0에서는 자체로 웹소켓WebSocket을 지원하는데, SockJS 구현체가 들어 있어 지원한다고 한다. SockJS가 서버의 연결이 끊어졌을 때 서버와 클라이언트가 서로 그 정보를 주고 받는 핑퐁(Ping-Pong, 이걸 핑퐁이라고 하는 것이군!)을 지원하지 않아 아쉽다고 하였는데, 과연 스프링에 포함되었을 때는 어떤 모습을 가질 수 있을지... 궁금하군.


개인적인 일정으로 여기까지만 듣고 Helloworld 세미나장을 나온다.

비가 내리는 날에도 많은 사람들이 참여한 세미나였고, 나로서는 처음 그린팩토리를 살펴볼 수 있는 좋은 기회였다. ㅎㅎ 하지만, 우리집(경기도 남양주시)에서 정자동까지는 멀고먼 여정이었다. Orz... 집에 돌아와서는 10시에 체력저하로 다운.

DB : sybase
Caused by: com.sybase.jdbc3.jdbc.SybSQLException: A wrong datastream has been sent to the server. The server was expecting token 32 but got the token 33. This is an internal error.
해당 쿼리를 실행시키기 위해 주어지는 paramaterClass(혹은 파라메터)에 null값이 없는지 확인해보기 바란다.

 

+ Recent posts