[Info]Tags categorized posts and contents patterns..

[AJAX] Ajax Code E xamples.. [Book] About the book.. [CSS] CSS Code E xamples.. [DB] Sql Code E xamples.. [DEV] All development stor...

2016년 8월 18일 목요일

[JAVA] Baekjoon 구구단을 출력해봅니다..

추억의 구구단 문제다.. 과거 대학교 시절 언어 수업 첫 과제가 구구단 짜기였는데.. 물론!!! 못맞췄다 ㅡㅡ.. 그 때는 언어를 내가 왜 해야되는지 몰랐기 때문에.. 지금보다 심각했다고 볼 수 있다.. 그런데 해당 문제는 약간 패턴이 틀린데 하나의 구구단 패턴만 표출하면 되는 것이라서 쉽다.. 아마도 초보 등급이어서 그런게 아닐까 싶다..

문제
N을 입력받은 뒤, 구구단 N단을 출력하는 프로그램을 작성하시오. 출력 형식에 맞춰서 출력하면 된다.

입력
첫째 줄에 N이 주어진다. N은 1보다 크거나 같고, 9보다 작거나 같다.

출력
출력형식과 같게 N*1부터 N*9까지 출력한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
package Code_201608;

import java.util.Scanner;

public class PrintForGuGuDan {

    @SuppressWarnings("resource")
    public static void main(String[] args) {
        // TODO Auto-generated method stub
  
        Scanner scan = new Scanner(System.in);
  
        //int a = 2;
        int a = scan.nextInt();
  
        for(int i = 1; i <= 9; i++) {
            System.out.println(a + " * " + i + " = " + a * i);
        }
    }

}//





내가 보기에 문제가 어렵지는 않지만, 내가 풀다보니 주의할점이 있다.. 과거에 구구단을 다출력하는 것을 생각하다보니 괜히 어렵게 생각을 했는데 출력에 대한 문구를 가만.. 보고 있으니 내가 오해를 한것이다.. 하나의 패턴을 출력하면 되는 것인데 괜시리.. 역시 이런 코딩 테스트는 간단함을 떠나서 문제의 의도를 잘 파악하고 출력하고자 하는 패턴을 잘 확인해야되는 것 같다..

[JAVA] Baekjoon N부터 1까지 숫자를 한 줄에 하나씩 출력해봅니다..

이번 문제는 앞선 문제와 정반대의 개념이다.. 순차적으로 숫자를 늘리는 것이 아니라 줄여가는 것이다.. 근데 꼭.. 난 이러한 역으로 하는 문제를 어려워한다.. 머리가 반대롤 도는걸 용납을 안하는건지.. ㅡ;;ㅡ..

이번에도 for 문 딱 작성하고서 그 안에 들어갈 코딩을 좀 생각을 했다.. 사고방식이 좀 유연해야되는데 너무 굳어진 느낌이 있다.. 이러한 연습을 통해서 좀 사라졌으면 한다..

문제
자연수 N이 주어졌을 때, N부터 1까지 한 줄에 하나씩 출력하는 프로그램을 작성하시오.

입력
첫째 줄에 100,000보다 작거나 같은 자연수 N이 주어진다.

출력
첫째 줄부터 N번째 줄 까지 차례대로 출력한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
package Code_201608;

import java.util.Scanner;

public class PrintForNTo1 {

    @SuppressWarnings("resource")
    public static void main(String[] args) {
        // TODO Auto-generated method stub
  
        Scanner scan = new Scanner(System.in);
  
        //int a = 5;
        int a = scan.nextInt();
  
        for(int i = a; i >= 1; i--) {
            System.out.println(i);
        }
    }

}//




[JAVA] Baekjoon 자연수 N이 주어졌을 때, 1부터 N까지 한 줄에 하나씩 출력하는 프로그램을 작성하시오..

드디어 그 앞에 과정, 입/출력 받아보기, 사칙연산 도전하기가 다 끝이 나고 이제부터는 for 문 사용하기로 들어간다.. 개발하면서 제일 어려운 것이 for 문이나 List, Array 등인데 난이도 하부터 올라가니까 차근 차근 잘해봐야겠다..

문제
자연수 N이 주어졌을 때, 1부터 N까지 한 줄에 하나씩 출력하는 프로그램을 작성하시오.

입력
첫째 줄에 100,000보다 작거나 같은 자연수 N이 주어진다.

출력
첫째 줄부터 N번째 줄 까지 차례대로 출력한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
package Code_201608;

import java.util.Scanner;

public class PrintFor1ToN {

    @SuppressWarnings("resource")
    public static void main(String[] args) {
        // TODO Auto-generated method stub
  
        Scanner scan = new Scanner(System.in);
  
        //int a = 5;
        int a = scan.nextInt();
  
        for(int i = 1; i <= a; i++) {
            System.out.println(i);
        }
    }

}//





문제를 보면 알겠지만 어려운 문제는 아니다.. 내가 아무리 for 문을 어려워한다지만.. 이정도는 풀어야겠지..?? 순차적으로 늘려나가는 패턴이다..


[JAVA] 19장 포틀릿(Portlet) MVC 프레임워크 #2..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

이 문서는 개인적인 목적이나 배포하기 위해서 복사할 수 있다. 출력물이든 디지털 문서든 각 복사본에 어떤 비용도 청구할 수 없고 모든 복사본에는 이 카피라이트 문구가 있어야 한다.

19.6 뷰와 뷰 처리
앞에서 언급했듯이 스프링 포틀릿 MVC가 직접 스프링 웹 MVC의 뷰 기술들을 모두 재사용한다. 이는 다양한 View 구현체들을 포함하지 않고 ViewResolver 구현체들도 포함하고 있지 않다는 뜻이다. 자세한 내용은 Chapter 17, 뷰 기술와 Section 16.5, “뷰 처리”를 각각 참조해 봐라.

존재하는 View와 ViewResolver 구현체를 사용할 때 몇가지 언급해야 할 것들이 있다.

  • 대 부분의 포탈(portal)은 포틀릿을 렌더링한 결과가 HTML 조각이 되기를 기대한다. 그러므로 JSP/JSTL, Velocity, FreeMarker, XSLT등이 모두 가능하다. 하지만 포틀릿에서는 다른 타입의 문서를 반환하는 뷰는 적당하지 않다.
  • 포틀릿내에서는 HTTP 리다이렉트 같은 것이 존재하지 않는다. (ActionResponse의 sendRedirect(..) 메서드는 포탈내에서 존재할 수 없다.) 그러므로 포틀릿 MVC 내에서는 RedirectView와 'redirect:' 접두사의 사용이 제대로 동작하지 않을 것이다.
  • 포틀릿 MVC에서 'forward:' 접두사를 사용할 수도 있다. 하지만 포틀릿이므로 현재 URL이 무엇인지 알 수 없다. 즉, 웹 어플리케이션에서 다른 리소스에 접근하는 상대 URL을 사용할수 없고 절대 URL을 사용해야 한다.

또한 JSP 개발에서 새로운 스프링 Taglib와 스프링 폼 Taglib 모두 포틀릿 뷰에서도 서블릿 뷰의 동작과 완전히 똑같히 동작한다.

19.7 멀티파트(파일 업로드) 지원
스프링 포틀릿 MVC에는 포틀릿 어플리케이션에서 웹 MVC처럼 파일 업로드를 다루는 멀티파트 지원을 내장하고 있다. 멀티파트 지원은 org.springframework.web.portlet.multipart 패키지에 정의된 플러그할 수 있는 PortletMultipartResolver 객체로 설계되었다. 스프링은 Commons FileUpload와 함께 사용할 수 있는 PortletMultipartResolver를 제공한다. 파일 업로드를 지원하는 방법은 이 섹션의 남은 부분에서 설명할 것이다.

일부 개발자들은 멀티파트를 직접 다루기 원하므로 기본적으로 스프링 포틀릿 MVC는 멀티파트를 처리하지 않을 것이다. 웹 어플리케이션 컨텍스트에 멀티파트 리졸버를 추가해서 직접 멀티파트 지원을 활성화해야 한다. 활성화하고 나면 DispatcherPortlet이 각 요청이 멀티파트인지 검사할 것이다. 멀티파트가 아니라면 요청은 기대대로 계속 된다. 하지만 요청이 멀티파트라면 컨텍스트에 선언한 PortletMultipartResolver를 사용할 것이다. 그 다음부터는 요청의 멀티파트 속성을 다른 속성처럼 다룰 것이다.

Note
설 정한 모든 PortletMultipartResolver 빈은 반드시 "portletMultipartResolver"라는 아이디(또는 이름)을 가져야 한다. 다른 이름으로 PortletMultipartResolver를 정의했다면 DispatcherPortlet가 PortletMultipartResolver를 찾지 못하므로 멀티파트 지원이 동작하지 않을 것이다.

19.7.1 PortletMultipartResolver의 사용
다음 예제는 CommonsPortletMultipartResolver를 사용하는 방법을 보여준다.


1
2
3
4
5
6
Xml

<bean id="portletMultipartResolver" class="org.springframework.web.portlet.multipart.CommonsPortletMultipartResolver">
  <!-- 사용할  있는 프로퍼티  하나; 파일의 최대 바이트 크기 -->
  <property name="maxUploadSize" value="100000"/>
</bean>

물론 멀티파트 리졸버가 동작하도록 클래스 패스에 적절한 jar도 둘어야 한다. CommonsMultipartResolver의 경우 commons-fileupload.jar를 사용해야 한다. Commons FileUpload의 과거의 버전은 JSR-168 포틀릿 어플리케이션을 지원하지 않으므로 최소한 1.1 버전의 Commons FileUpload를 사용해야 한다.

포틀릿 MVC가 멀티파트 요청을 처리하도록 설정하는 방법을 보았으니 이제 실제로 어떻게 사용하는지 보자. DispatcherPortlet가 멀티파트 요청을 발견하면 DispatcherPortlet가 컨텍스트에 선언한 리졸버를 활성화하고 요청을 전달한다. 그 다음 리졸버는 ActionRequest을 멀티파트 파일 업로드를 지원하는 MultipartActionRequest로 감싼다. MultipartActionRequest를 사용해서 해당 요청의 멀티파트 정보를 얻을 수 있고 컨트롤러에서 멀티파트 파일 자체에 실제로 접근할 수 있다. RenderRequest의 일부가 아니라 ActionRequest의 일부로만 멀티파트 파일을 받을 수 있다는 점을 기억해라.

19.7.2 폼의 파일 업로드 처리
PortletMultipartResolver 가 자신의 작업을 완료한 후에 요청은 다름 요청과 마찬가지로 처리된다. PortletMultipartResolver를 사용하려면 업로드 필드를 가진 폼(아래 예제 참고)을 생성하고 스프링이 파일을 폼(지원 객체, backing object)에 바인딩하도록 한다. 실제로 사용자가 파일을 업로드하게 하려면 (JSP/HTML) 폼을 생성해야 한다.


1
2
3
4
5
6
7
Xml

<h1>Please upload a file</h1>
<form method="post" action="<portlet:actionURL/>" enctype="multipart/form-data">
  <input type="file" name="file"/>
  <input type="submit"/>
</form>

여기서 보듯이 byte[] 배열을 담고 있는 빈의 프로퍼티와 일치하는 “file”라는 이름의 필드를 생성했다. 게다가 브라우저가 멀티파트 필드를 어떻게 인코딩해야 하는지 알 수 있도록 인코딩 속성(enctype="multipart/form-data")을 추가했다.(이 부분을 잊지 마라!)

순식간에 문자열이나 프리미티브 타입으로 변환할 수 없는 다른 프로퍼티와 마찬가지로 객체에 바이너리 데이터를 보관하려면 PortletRequestDataBinder로 커스텀 에디터를 등록해야 한다. 파일을 다루고 객체에 설정하는데 사용할 수 있는 두개의 에디터가 존재한다. 파일을 문자열(사용자가 정의한 캐릭터셋(character set)을 사용해서)로 변환하는 StringMultipartFileEditor와 파일을 바이트 배열로 변환하는 ByteArrayMultipartFileEditor가 있다. 이 기능들은 CustomDateEditor와 유사하다.

그러므로 폼을 사용해서 파일을 업로드하게 하려면 리졸버, 빈을 처리할 컨트롤러에 대한 매칭과 컨트롤러를 선언한다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
Xml

<bean id="portletMultipartResolver"
    class="org.springframework.web.portlet.multipart.CommonsPortletMultipartResolver"/>

<bean class="org.springframework.web.portlet.handler.PortletModeHandlerMapping">
  <property name="portletModeMap">
    <map>
      <entry key="view" value-ref="fileUploadController"/>
    </map>
  </property>
</bean>

<bean id="fileUploadController" class="examples.FileUploadController">
  <property name="commandClass" value="examples.FileUploadBean"/>
  <property name="formView" value="fileuploadform"/>
  <property name="successView" value="confirmation"/>
</bean>

이렇게 한 후 컨트롤러와 파일 프로퍼티를 가진 실제 클래스를 생성한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Java

public class FileUploadController extends SimpleFormController {

  public void onSubmitAction(ActionRequest request, ActionResponse response,
    Object command, BindException errors) throws Exception {

    // 빈을 캐스팅한다
    FileUploadBean bean = (FileUploadBean) command;

    // 내용이 존재하는지 확인한다
    byte[] file = bean.getFile();
    if (file == null) {
      // 흠.. 뭔가 잘못됐다. 사용자가 아무것도 업로드하지 않았다
    }

    // 여기서 파일로 어떤 작업을 한다
  }

  protected void initBinder(
      PortletRequest request, PortletRequestDataBinder binder) throws Exception {
    // 실제로 Multipart 인스턴스를 byte[]로 변환할 수 있게 하려면
    // 커스텀 에디터를 등록해야 한다
    binder.registerCustomEditor(byte[].class, new ByteArrayMultipartFileEditor());
    // 이제 스프링이 멀티파트 객체를 어떻게 다루고 어떻게 변환하는지 알고 있다
  }
}

public class FileUploadBean {
  private byte[] file;

  public void setFile(byte[] file) {
    this.file = file;
  }

  public byte[] getFile() {
    return file;
  }
}

여기서 보듯이 FileUploadBean은 파일을 담고 있는 byte[] 타입의 프로퍼티를 가진다. 컨트롤러는 스프링이 멀티파트 객체를 실제로 변환하는 방법을 알게 하고 리볼버가 빈이 지정한 프로퍼티를 찾도록 하는 커스텀 에디터를 등록한다. 이 예제에서는 빈의 byte[] 프로퍼티 자체로는 아무것도 하지 않지만 실사례에서는 원하는 무엇이든지 할 수 있다.(데이터베이스에 저장하거나 누군가에게 메일로 보내는 등)

폼을 지원하는 객체(form backing object)의 문자열 타입의 프로퍼티에 직접 바인딩되는 동일한 예제는 다음과 같을 것이다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
Java

public class FileUploadController extends SimpleFormController {

  public void onSubmitAction(ActionRequest request, ActionResponse response,
      Object command, BindException errors) throws Exception {

    // 빈을 캐스팅한다
    FileUploadBean bean = (FileUploadBean) command;

    // 내용이 존재하는지 검사한다
    String file = bean.getFile();
    if (file == null) {
      // 흠.. 뭔가 잘못됐다. 사용자가 아무것도 업로드하지 않았다
    }

    // 여기서 파일로 어떤 작업을 한다
  }

  protected void initBinder(
    PortletRequest request, PortletRequestDataBinder binder) throws Exception {

    // 실제로 Multipart 인스턴스를 문자열로 변환할 수 있게 하려면
    // 커스텀 에디터를 등록해야 한다
    binder.registerCustomEditor(String.class,
      new StringMultipartFileEditor());
    // 이제 스프링이 멀티파트 객체를 어떻게 다루고 어떻게 변환하는지 알고 있다
  }
}

public class FileUploadBean {

  private String file;

  public void setFile(String file) {
    this.file = file;
  }

  public String getFile() {
    return file;
  }
}

물론 이 마지막 예제는 평범한 텍스트 파일을 업로드하는 경우에만 (논리적으로) 말이된다. (이미지 파일을 업로드하는 경우에는 제대로 동작하지 않을 것이다.)

세 번째(그리고 마지막) 선택사항은 (폼을 지원하는) 객체의 클래스에 선언한 MultipartFile 프로퍼티에 직접 바인딩하는 것이다. 이 경우에는 타입 변환을 수행할 필요가 없으므로 어떤 커스텀 프로퍼티 에디터도 등록할 필요가 없다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Java

public class FileUploadController extends SimpleFormController {

  public void onSubmitAction(ActionRequest request, ActionResponse response,
      Object command, BindException errors) throws Exception {

    // 빈을 캐스팅한다
    FileUploadBean bean = (FileUploadBean) command;

    // 내용이 존재하는지 검사한다
    MultipartFile file = bean.getFile();
    if (file == null) {
      // 흠.. 뭔가 잘못됐다. 사용자가 아무것도 업로드하지 않았다
    }

    // 여기서 파일로 어떤 작업을 한다
  }
}

public class FileUploadBean {

  private MultipartFile file;

  public void setFile(MultipartFile file) {
    this.file = file;
  }

  public MultipartFile getFile() {
    return file;
  }
}

19.8 예외 처리
서블릿 MVC와 마찬가지로 포틀릿 MVC도 요청에 적합한 핸들러가 요청을 처리하는 도중에 발생한 의도하지 않는 예외를 쉽게 처리해주는 HandlerExceptionResolver를 제공한다. 포틀릿 MVC도 던져질 예의의 클래스명을 받아서 뷰 이름에 매핑할 수 있도록 포틀릿에 한정된 구현체 SimpleMappingExceptionResolver를 제공한다.

19.9 어노테이션에 기반한 컨트롤러 구성
스프링 2.5는 @RequestMapping, @RequestParam, @ModelAttribute 등의 어노테이션을 사용해서 MVC 컨트롤러에 어노테이션에 기반한 프로그래밍 모델을 도입했다. 이 어노테이션 지원은 서블릿 MVC와 포틀릿 MVC 모두에서 사용할 수 있다. 이 방식으로 구현한 컨트롤러는 특정 기반 클래스를 확장하거나 특정 인터페이스를 구현하지 않는다. 게다가 원한다면 서블릿이나 포틀릿 기능에 쉽게 접근할 수 있기는 하지만 보통은 서블릿이나 포틀릿 API에 직접 의존성을 갖지 않는다.

다음 섹션에서는 이러한 어노테이션을 포틀릿 환경에서 보통 어떻게 사용하는지 설명한다.

19.9.1 어노테이션 지원에 대한 디스패처 설정
디스패처에 대응되는 HandlerMapping(타입 수준의 어노테이션에서)이나 HandlerAdapter(메서드 수준의 어노테이션에서)이 존재하는 경우에만 @RequestMapping를 처리할 것이다. 이 동작이 DispatcherServlet과 DispatcherPortlet에서 모두 기본값이다.

하지만 커스텀 HandlerMappings이나 HandlerAdapters를 정의했다면 대응되는 DefaultAnnotationHandlerMapping나 AnnotationMethodHandlerAdapter도 역시 정의해야 한다. (@RequestMapping를 사용할 것이라면)


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
Xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

  <bean class="org.springframework.web.portlet.mvc.annotation.DefaultAnnotationHandlerMapping"/>

  <bean class="org.springframework.web.portlet.mvc.annotation.AnnotationMethodHandlerAdapter"/>

  // ... (컨트롤러 빈 정의) ...
</beans>

매핑 전략을 커스터마이징한다면 DefaultAnnotationHandlerMapping이나 AnnotationMethodHandlerAdapter를 명시적으로 정의하는 것도 절적하다. 예를 들어 커스텀 WebBindingInitializer를 지정하는 것 등이다.(아래 참조)

19.9.2 @Controller로 컨트롤러 정의하기
@Controller 어노테이션은 특정 클래스가 컨트롤러의 역할을 한다는 것을 나타낸다. 여기서 어떤 기반 컨트롤러 클래스를 확장하거나 포틀릿 API를 참조할 필요가 없다. 필요하다면 여전히 포틀릿에 특화된 기능을 참조할 수 있다.

@Controller 어노테이션의 기본적인 목적은 어노테이션이 붙은 클래스에 스테레오타입으로(클래스의 역할을 나타내면서) 동작하는 것이다. 디스패처는 매핑된 메서드와 @RequestMapping 어노테이션을 참조하기 위해서 이렇게 어노테이션이 붙은 클래스를 스캔할 것이다.(다음 섹션을 참고해라.)

어노테이션이 붙은 컨트롤러 빈은 디스패처의 컨텍스트에서 표준 스프링 빈 정의를 사용해서 명시적으로 정의할 것이다. 하지만 @Controller 스테레오타입도 클래스패스의 컴포넌트 클래스 탐지와 이 클래스들의 빈 정의의 자동 등록에 대한 스프링 2.5의 일반적인 지원으로 자동탐지를 허용한다.

이렇게 어노테이션이 붙은 컨트롤러의 자동탐지를 활성화하려면 설정에 컴포넌트 스캔을 추가해야 한다. 이는 다음 XML 코드에서 보듯이 spring-context 스키마를 사용해서 쉽게 추가할 수 있다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
Xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:p="http://www.springframework.org/schema/p"
  xmlns:context="http://www.springframework.org/schema/context"
  xsi:schemaLocation="
    http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
    http://www.springframework.org/schema/context
    http://www.springframework.org/schema/context/spring-context-3.0.xsd">

  <context:component-scan base-package="org.springframework.samples.petportal.portlet"/>

  // ...
</beans>

19.9.3 @RequestMapping로 요청 매핑하기
@RequestMapping 어노테이션은 전체 클래스나 특정 핸들러 메서드에 'VIEW'/'EDIT'같은 포틀릿 모드를 매핑하는데 사용한다. 보통 타입수준의 어노테이션은 폼 컨트롤러에 특정 모드(또는 모드에 파라미터를 추가한 상황)를 매핑하고 추가적인 메서드 수준의 어노테이션은 특정 포틀릿 요청 파라미터로 주요 매핑을 '제한'한다.

Tip
타입 수준의 @RequestMapping은 Controller의 평범함 구현체에도 사용할 것이다. 이 경우에 요청을 처리하는 코드는 전통적인 handle(Action|Render)Request 시그니처를 따를 것이지만 컨트롤러의 매핑은 @RequestMapping 어노테이션으로 표현할 것이다. 이는 SimpleFormController같은 미리 만들어진(pre-built) Controller 기반 클래스에서도 동작한다.
다음 부분에서 어노테이션이 붙은 핸들러 메서드에 기반한 컨트롤러를 다룰 것이다.

다음은 이 어노테이션을 사용한 PetPortal 예제 어플리케이션의 폼 컨트롤러 예제이다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
Java

@Controller
@RequestMapping("EDIT")
@SessionAttributes("site")
public class PetSitesEditController {

  private Properties petSites;

  public void setPetSites(Properties petSites) {
    this.petSites = petSites;
  }

  @ModelAttribute("petSites")
  public Properties getPetSites() {
    return this.petSites;
  }

  @RequestMapping  // 기본값 (action=list)
  public String showPetSites() {
    return "petSitesEdit";
  }

  @RequestMapping(params = "action=add")  // 렌더링 단계
  public String showSiteForm(Model model) {
    // 최초의 폼과 오류를 다시 보여주는 데 사용한다
    if (!model.containsAttribute("site")) {
      model.addAttribute("site", new PetSite());
    }
    return "petSitesAdd";
  }

  @RequestMapping(params = "action=add")  // 액션 단계
  public void populateSite(
      @ModelAttribute("site") PetSite petSite, BindingResult result,
      SessionStatus status, ActionResponse response) {

    new PetSiteValidator().validate(petSite, result);
    if (!result.hasErrors()) {
      this.petSites.put(petSite.getName(), petSite.getUrl());
      status.setComplete();
      response.setRenderParameter("action", "list");
    }
  }

  @RequestMapping(params = "action=delete")
  public void removeSite(@RequestParam("site") String site, ActionResponse response) {
    this.petSites.remove(site);
    response.setRenderParameter("action", "list");
  }
}

19.9.4 지원하는 핸들러 메서드 아규먼트
@RequestMapping 어노테이션이 붙은 핸들러 메서드는 아주 유연한 시그니처를 가질 수 있게 한다. 이 메서드는 임의의 순서(원한다면 커맨드 객체뒤에 와야 하는 대응되는 유효성 검사 결과를 제외하고)로 다음 타입의 인자를 가질 것이다.

  • 요청 또는 응답 객체(포틀릿 API). PortletRequest / ActionRequest / RenderRequest같은 특정 요청/응답 타입을 선택할 것이다. 명시적으로 선언한 action/render 인자도 핸들러 메서드에 특정 요청 타입을 매핑하는데 사용한다.(action과 render 요청을 구별하는 어떤 정보도 주어지지 않은 경우에)
  • PortletSession 타입의 세션 객체 (포틀릿 API). 이 타입의 인자는 대응되는 세션에 존재하게 강제할 것이다. 그 결과 이러한 인자는 null이 되지 않을 것이다.
  • org.springframework.web.context.request.WebRequest 나 org.springframework.web.context.request.NativeWebRequest. 네이티브 서블릿/포틀릿 API에 의존하지 않고 요청/세션 속성 접근과 마찬가지로 일반적인 요청 파라미터의 접근을 허용한다.
  • 현재 요청 로케일에 대한 java.util.Locale (포틀릿 환경의 포탈(portal) 로케일)
  • 요청의 내용에 접근하는 java.io.InputStream / java.io.Reader. 이는 포틀릿 API가 노출하는 로우(raw) InputStream/Reader가 될 것이다.
  • 응답의 내용을 생성하는 java.io.OutputStream / java.io.Writer. 이는 포틀릿 API가 노출하는 로우(raw) OutputStream/Writer가 될 것이다.
  • 특정 포틀릿 요청 파라미터에 접근하는 @RequestParam 어노테이션이 붙은 파라미터들. 파라미터 값을 선언한 메서드 인자 타입으로 변환할 것이다.
  • 웹 뷰에 노출될 암시적인(implicit) 모델을 풍부하게 하는 java.util.Map / org.springframework.ui.Model / org.springframework.ui.ModelMap.
  • @InitBinder 메서드나 HandlerAdapter 설정에 의존하면서 커스터마이징할 수 있는 타입 변환으로 빈 프로퍼티나 필드로 파라미터에 바인드할 Command/form 객체. (AnnotationMethodHandlerAdapter에 "webBindingInitializer" 프로퍼티를 봐라.) 이러한 커맨드 객체와 그 유효성검사 결과는 기본적으로 프로퍼티 표시법(notation)으로 정규화되지 않은 커맨드 클래스를 사용해서 모델 속성으로 노출될 것이다.(예를 들면 "mypackage.OrderAddress" 타입의 "orderAddress") 특정 모델 속성 이름을 선언하려면 파라미터 수준의 ModelAttribute 어노테이션을 지정해라.
  • 앞의 command/form 객체(바로 앞의 인자)에 대한 org.springframework.validation.Errors / org.springframework.validation.BindingResult 유효성검사 결과.
  • 폼 처리를 완료로 표시하는 org.springframework.web.bind.support.SessionStatus 산태 핸들. (핸들러 타입 수준의 @SessionAttributes 어노테이션이 가리키는 세션 속성을 정리한다.)
핸들러 메서드는 다음의 반환 타입을 지원한다.
  • 커맨드객체와 @ModelAttribute 어노테이션이 붙은 참조 데이터 접근자 메서드의 결과로 암묵적으로 풍부해진 모델을 가진 ModelAndView 객체.
  • RequestToViewNameTranslator로 암묵적으로 결정된 뷰 이름과 커맨드객체와 @ModelAttribute 어노테이션이 붙은 참조 데이터 접근자 메서드의 결과로 암묵적으로 풍부해진 모델을 가진 Model 객체.
  • RequestToViewNameTranslator 로 암묵적으로 결정한 뷰이름을 가진 모델을 노출하는 Map 객체로 모델은 커맨드 객체와 @ModelAttribute 어노테이션이 붙은 참조 데이터 접근자 메서드의 결과로 암묵적으로 풍부해진다.
  • 커맨드 객체와 @ModelAttribute 어노테이션이 붙은 참조 데이터 접근자 메서드로 암묵적으로 결정된 모델을 가진 View 객체. Model 인자를 선언해서(앞부분 참고) 핸들러 메서드도 모델을 프로그래밍적으로 강화할 수도 있다.
  • 뷰 이름으로 해석되는 String 값으로커맨드 객체와 @ModelAttribute 어노테이션이 붙은 참조 데이터 접근자 메서드로 암묵적으로 결정된 모델을 가진다. Model 인자를 선언해서(앞부분 참고) 핸들러 메서드도 모델을 프로그래밍적으로 강화할 수도 있다.
  • 메서드가 직접 응답을 처리하면 void이다. (예를 들면 응답 내용을 직접 작성하는 등)
  • 다 른 모든 반환 타입은 메서드 수준의 @ModelAttribute로 지정한 속성명을 사용해서(그렇지 않으면 방환 타입의 클래스에 기반한 기본 속성명) 뷰로 노출하는 단일 모델 속성으로 간주할 것이다. 모델은 커맨드 객체와 @ModelAttribute 어노테이션이 붙은 참조 데이터 접근자 메서드의 결과로 암묵적으로 풍부해진다.

19.9.5 @RequestParam로 요청 파라미터를 메서드 파라미터로 바인딩하기
컨트롤러에서 요청 파라미터를 메서드 파라미터로 바인딘하는데 @RequestParam 어노테이션을 사용한다.

PetPortal 예제 어플리케이션의 다음 코드는 @RequestParam의 사용방법을 보여준다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
Java

@Controller
@RequestMapping("EDIT")
@SessionAttributes("site")
public class PetSitesEditController {

  // ...

  public void removeSite(@RequestParam("site") String site, ActionResponse response) {
    this.petSites.remove(site);
    response.setRenderParameter("action", "list");
  }

  // ...
}

이 어노테이션을 사용한 파라미터들은 기본적으로 필수값이지만 @RequestParam의 required 속성을 false로 지정해서 해당 파라미터를 선택적인 값으로 지정할 수 있다. (예시: @RequestParam(value="id", required=false))

19.9.6 @ModelAttribute이 붙은 모델에서 데이터로의 링크 제공하기
@ModelAttribute 은 컨트롤러에서 두가지 사용 시나리오를 가진다. 메서드 파라미터에 사용한 경우 모델 속성을 어노트에션이 붙은 특정 메서드 파라미터에 매핑할 때 사용한다.(다음 예제의 populateSite() 메서드를 봐라.) 이것이 컨트롤러가 폼에서 들어온 데이터를 가진 객체에 대한 참조를 얻는 방법이다. 게다가 파라미터를 일반적인 java.lang.Object가 아니라 폼 지원 객체(form backing object)의 특정 타입으로 선언할 수 있으므로 타입 안정성을 높혀준다.

@ModelAttribute 을 모델에 대한 참조 데이터(reference data)를 제공하려고 메서드 수준에서 사용할 수도 있다. (다음 예제의 getPetSites()를 봐라.) 이 사용방법에서는 메서드 시그니처가 위의 @RequestMapping 어노테이션에서 문서화된 것과 같은 타입을 담고 있을 수 있다.

Note: @ModelAttribute 어노테이션이 붙은 메서드는 선택된 @RequestMapping 어노테이션이 붙은 핸들러 메서드 이전에 실행될 것이다. 이 메서드들은 효율적으로 특성 속성(때로는 데이터베이스에서 가져온)을 가진 암묵적인 모델을 미리 존재하게 한다. 이러한 속성은 선택된 핸들러 메서드에서 @ModelAttribute 어노테이션이 붙은 핸들러 메서드(잠재적으로 바인딩과 유효성검사를 적용해서)를 통해서 이미 접근했을 수 있다. 다음 예제 코드는 이 어노테이션의 두가지 사용방법을 보여준다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Java

@Controller
@RequestMapping("EDIT")
@SessionAttributes("site")
public class PetSitesEditController {

  // ...

  @ModelAttribute("petSites")
  public Properties getPetSites() {
    return this.petSites;
  }

  @RequestMapping(params = "action=add")  // action 단계
  public void populateSite(
      @ModelAttribute("site") PetSite petSite, BindingResult result,
      SessionStatus status, ActionResponse response) {

    new PetSiteValidator().validate(petSite, result);
    if (!result.hasErrors()) {
      this.petSites.put(petSite.getName(), petSite.getUrl());
      status.setComplete();
      response.setRenderParameter("action", "list");
    }
  }
}

19.9.7 @SessionAttributes로 세션에 저장할 속성 지정하기
최 상위 @SessionAttributes 어노테이션은 특정 핸들러가 사용하는 세션 속성을 선언한다. 이는 보통 모델 속성의 이름이나 모델 속성의 타입의 목록이 될 것이고 이 모델 속성은 투명하게 세션이나 대화식 스토리지에에 저장해야 하고 뒤이은 요청간에 폼지원 빈으로 제공한다. 다음 코드는 이 어노테이션의 사용방법을 보여준다.


1
2
3
4
5
6
7
8
Java

@Controller
@RequestMapping("EDIT")
@SessionAttributes("site")
public class PetSitesEditController {
  // ...
}

19.9.8 WebDataBinder 초기화 커스터마이징
스 프링의 WebDataBinder를 통해서 PropertyEditor 등으로 요청 파라미터 바인딩을 커스터마이징하려면 컨트롤러내에서 @InitBinder 어노테이션이 붙은 메서드를 사용하거나 커스텀 WebBindingInitializer를 제공해서 설정을 외부로 내낼 수 있다(externalize).

19.9.8.1 @InitBinder로 데이터 바인딩 커스터마이징하기
@InitBinder 어노테이션이 붙은 컨트롤러 메서드로 컨트롤러 클래스에서 웹 데이터 바인딩을 직접 설정할 수 있다. @InitBinder는 어노테이션이 붙은 핸들러 메서드의 커맨드와 폼 객체 아규먼트를 유지하는데 사용할 WebDataBinder를 초기화하는 메서드를 식별한다.

이러한 init-binder 메서드는 @RequestMapping이 지원하는 아규먼트 중 커맨드/폼 객체와 이에 대응되는 유효성검사 결과 객체를 제외한 모든 아규먼트를 지원한다. init-binder 메서드는 반드시 반환값을 갖지 않아야 한다. 그러므로 일반적으로 void로 선언한다. 전형적인 아규먼트는 컨텍스트에 특화된 에디터를 등록하는 코드를 허용하는 WebRequest나 java.util.Locale를 조합한 WebDataBinder를 포함한다.

다음 예제는 모든 java.util.Date 폼 프로퍼티에 대한 CustomDateEditor를 설정하는 @InitBinder의 사용방법을 보여준다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
Java

@Controller
public class MyFormController {

  @InitBinder
  public void initBinder(WebDataBinder binder) {
    SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");
    dateFormat.setLenient(false);
    binder.registerCustomEditor(Date.class, new CustomDateEditor(dateFormat, false));
  }

  // ...
}

19.9.8.2 커스텀 WebBindingInitializer 설정
데 이터 바인딩 초기화를 외부화하려고 WebBindingInitializer 인터페이스의 커스텀 구현체를 제공할 수 있고 AnnotationMethodHandlerAdapter의 커스텀 빈 설정을 제공해서 활성화하므로 기본 설정을 오버라이딩한다.

19.10 포틀릿 어플리케이션 배포
스프링 포틀릿 MVC 어플리케이션을 배포하는 과정은 JSR-168 포틀릿 어플리케이션을 배포하는 과정과 다르지 않다. 하지만 이 부분은 좀 헷갈리므로 여기서 간략히 얘기하고자 한다.

보 통 포탈(portal)/포틀릿 컨테이너는 서블릿 컨테이터에서 웹앱(webapp)에서 실행되고 포틀릿은 서블릿 컨데이터의 다른 웹앱에서 실행된다. 포틀릿 컨테이너 웹앱이 포틀릿 웹앱을 호출하게 하려면 portlet.xml 파일에 정의한 포틀릿 서비스에 접근할 수 있는 잘 알려진 서블릿을 호출하는 교차컨텍스트(cross-context)를 구성해야 한다.

JSR-168 명세가 이 부분이 어떻게 이뤄지는지 정확히 명시하지 않으므로 각 포틀릿 컨테이너는 이 부분에 대한 자신만의 메카니즘을 가진다. 이 메카니즘은 보통 포틀릿 웹 앱 자체를 변경하는 종류의 "배포 과정"을 포함하고 있고 배포 과정후에 포틀릿 컨테이너 내에 포틀릿을 등록한다.

포틀릿 컨테이너가 호출할 유명한 서블릿을 주입하기 위해 포틀릿 웹앱의 web.xml를 최소한으로 수정한다. 일부의 경우 단일 서블릿이 웹앱의 모든 포틀릿을 서비스하지만 각 포틀릿마다 서블릿 인스턴스가 존재하는 경우도 있다.

일부 포틀릿 컨테이너도 웹앱에 라이브러리나 설정 파일을 주입할 것이다. 포틀릿 컨테이너도 웹앱에서 사용할 수 있는 Portlet JSP Tag Library 구현체를 구성해야 한다.

배포(deployment)를 이해하는데 중요한 요점은 대상 포탈(porta)이 필요하고 포탈과 만나도록 해야한다는 것이다.(보통은 자동화된 배포과정으로 제공한다.) 이 과정에 대한 포탈(portal)의 문서를 자세히 읽어봐라.

포틀릿을 배포하고 나면 최종 web.xml 파일이 정상정인지 살펴봐라. 일부 오래된 포탈은 ViewRendererServlet 정의를 잘못되게 하므로 포틀릿 렌더링을 깨뜨린다.

[JAVA] 19장 포틀릿(Portlet) MVC 프레임워크 #1..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

이 문서는 개인적인 목적이나 배포하기 위해서 복사할 수 있다. 출력물이든 디지털 문서든 각 복사본에 어떤 비용도 청구할 수 없고 모든 복사본에는 이 카피라이트 문구가 있어야 한다.

19. 포틀릿(Portlet) MVC 프레임워크
19.1 소개

JSR-168 자바 포틀릿 명세
포틀릿 개발과 관련한 일반적인 정보는 Sun이 작성한 "JSR 168 소개"와 JSR-168 명세를 보기 바란다.

전통적인 (서블릿 기반의) 웹 개발 지원에 추가적으로 스프링은 JSR-168 포틀릿 개발도 지원한다. 포틀릿 MVC 프레임워크는 웹 MVC 프레임워크의 복사판과도 같고 동일한 뷰 추상화와 통합 기술을 사용한다. 그러므로 이번 장을 읽기 전에 Chapter 16, 웹 MVC 프레임워크장과 Chapter 17, 뷰 기술 장을 읽어봐라.

Note
스프링 MVC의 개념이 스프링 포틀릿 MVC에서도 동일하지만 JSR-168 포틀릿의 독특한 흐름(workflow)으로 생겨난 주요한 차이점이 있다는 점을 명심해라.

서블릿의 흐름과 다른 포틀릿의 흐름은 포틀릿으로의 요청이 액션(action) 단계와 렌더링(render) 단계의 두 단계로 구분될 수 있다는 것이다. 액션 단계는 데이터베이스의 변경같은 '백엔드'의 변경사항이나 액션이 일어났을 때 딱 한번만 실행된다. 그 다음 렌더링 단계가 화면을 갱신할 때마다 사용자에게 보여줄 내용을 만든다. 여기서 중요한 점은 하나의 전체 요청에서 액션 단계는 딱 한번만 실행되지만 렌더링 단계는 여러번 실행될 수 있다는 것이다. 이는 시스템의 상태를 변경하는 활동과 사용자에게 보여줄 내용을 생성하는 활동을 깔끔하게 구분해준다. (구분해야 한다)

스프링 웹 플로우(Spring Web Flow)
스프링 웹 플로우 (SWF, Spring Web Flow)는 웹 어플리케이션 페이지 흐름을 관리하는 최상의 솔루션이다.

SWF는 서블릿 환경과 포틀릿 환경에서 모두에서 스프링 MVC, 스트럿츠, JSF같은 프레임워크와 통합한다. 순사하게 요청 모델과는 반대로 대화식 모델의 이점을 갖는 비즈니스 처리과정을 가진다면 SWF가 해결책이 될 것이다.

SWF는 여러 상황에서 재사용할 수 있는 내장된 모쥴처럼 논리적인 페이지 흐름을 갖을 수 있도록 하고 비즈니스 처리과정을 유도하는 제어된 네비게이션드로 사용자를 도와주는 웹 어플리케이션 모듈을 구성하는데 최적이다.

SWF에 대한 자세한 내용은 Spring Web Flow 웹사이트를 참고해라.

포틀릿 요청의 이중 단계는 JSR-168 명세의 진짜 강점 중 하나이다. 예를 들어 사용자가 명시적으로 검색을 재실행하지 않아도 동적인 검색 결과의 화면을 언제나 갱신할 수 있다. 대부분의 다른 포틀릿 MVC 프레임워크는 개발자한테 이 두 단계를 완전히 감추고 가능한한 일반적인 서블릿 개발처럼 보이도록 한다. 스프링 개발팀은 이 접근이 포틀릿을 사용하는 주요한 이점을 없앤다고 생각한다. 그래서 스프링 포틀릿 MVC 프레임워크에서 두 단계의 구분은 유지된다. 이 접근방법의 주요한 영향으로 MVC 클래스의 서블릿 버전이 요청을 다루는 하나의 메서드를 가질 때 MVC 클래스의 포틋릿 버전은 요청을 다루는 두 메서드를 가질 것이다.(하나는 액션단계용이고 하나는 렌더링단계용이다.) 예를 들어 AbstractController의 서블릿 버전은 handleRequestInternal(..) 메서드를 가지지만 AbstractController의 포틀릿 버전은 handleActionRequestInternal(..)와 handleRenderRequestInternal(..) 메서드를 가진다.

포틀릿 프레임워크는 웹 프레임워크에서 DispatcherServlet가 하듯이 요청을 핸들러로 디스패치하는 DispatcherPortlet을 기반으로 설계되었고 설정가능한 핸들러 매핑과 뷰 처리를 제공한다. 파입업로드도 같은 방법으로 지원한다.

포틀릿 MVC에서는 로케일 처리와 테마 처리를 지원하지 않는다. 이 영역은 포탈(portal)/포틀릿 컨테이너의 범위이므로 스프링 수준에서 다루기는 적합하지 않다. 하지만 로케일에 기반한 스프링의 모든 메카니즘은(메시지의 국제화 등) DispatcherPortlet가 DispatcherServlet과 같은 방법으로 현재 로케일을 노출하므로 기능이 제대로 동작할 것이다.

19.1.1 컨트롤러 - MVC에서 C
기본 핸들러는 여전히 아주 간단한 Controller 인터페이스이고 두 메서드를 제공한다.

  • void handleActionRequest(request,response)
  • ModelAndView handleRenderRequest(request,response)
포틀릿 프레임워크는 AbstractController, SimpleFormController처럼 거의 동일한 컨트롤러 구현체 계층을 가진다. 데이터 바인딩, 커맨드 객체의 사용, 모델 처리, 뷰 처리는 서블릿 프레임워크와 완전히 동일하다.

19.1.2 뷰 - MVC에서 V
ViewRendererServlet라는 특수한 브릿지 서블릿으로 서블릿 프레임워크의 모든 뷰 렌더링 기능을 직접 사용한다. 이 서블릿을 사용해서 포틀릿 요청을 서블릿 요청으로 변환하고 일반적인 서블릿 인프라 전체를 사용해서 뷰를 렌더링할 수 있다. 이는 JSP, Velocity 등 기존에 존재하는 렌더러 모두를 포틀릿에서도 계속해서 사용할 수 있음을 의미한다.

19.1.3 웹의 범위를 갖는(Web-scoped) 빈
스프링 포틀릿 MVC는 생명주기가 현재 HTTP 요청이나 HTTP Session(일반적인 세션이나 전역 세션 모두)의 범위를 갖는 빈을 지원한다. 이는 스프링 포틀릿 MVC 자체의 특정 기능이라기 보다는 스프링 포틀릿 MVC가 사용하는 WebApplicationContext 컨테이너의 기능이다. 이러한 빈의 범위는 Section 4.5.4, “리퀘스트, 세션, 글로벌 세션 범위”에서 설명한다.

19.2 DispatcherPortlet
포틀릿 MVC는 요청을 컨트롤러로 디스패치하고 포틀릿 어플리케이션을 개발하는 기반 기능을 제공하는 포틀릿에 기반해서 설계된 요청주도 웹 MVC 프레임워크이다. 하지만 스프링의 DispatcherPortlet는 이 이상을 수행한다. DispatcherPortlet은 스프링 ApplicationContext와 완전히 통합되었고 스프링이 가진 모든 기능을 사용할 수 있게 한다.

일반적인 포틀릿처럼 DispatcherPortlet는 웹 어플리케이션의 portlet.xml 파일에 선언한다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
Xml

<portlet>
  <portlet-name>sample</portlet-name>
  <portlet-class>org.springframework.web.portlet.DispatcherPortlet</portlet-class>
  <supports>
    <mime-type>text/html</mime-type>
    <portlet-mode>view</portlet-mode>
  </supports>
  <portlet-info>
    <title>Sample Portlet</title>
  </portlet-info>
</portlet>

이제 DispatcherPortlet를 설정해야 한다.

포틀릿 MVC 프레임워크에서 각 DispatcherPortlet는 루트 WebApplicationContext에 이미 정의된 모든 빈을 상속받은 자신만의 WebApplicationContext를 가진다. 이 상속된 빈은 포틀릿에 한정된 범위에서 오버라이드할 수 있고 새로운 범위로 한정된 빈은 해당 포틀릿 인스턴스의 로컬로 정의할 수 있다.

DispatcherPortlet 초기화시 포틀릿 MVC 프레임워크는 웹 어플리케이션의 WEB-INF 디렉토리에서 [portlet-name]-portlet.xml라는 파일을 검색해서 정의된 빈을 생성한다.(전역 범위에 같은 이름으로 정의된 모든 빈 정의는 오버라이드한다.)

DispatcherPortlet가 사용하는 설정 위치는 포틀릿 초기화 파라미터로 수정할 수 있다.(자세한 내용은 뒤에 나온다.)

스프링 DispatcherPortlet는 요청을 처리하고 적절한 뷰를 렌더링하는 데 사용하는 몇몇 특수한 빈을 가진다. 이러한 빈은 스프링 프레임워크에 포함되어 있고 설정할 다른 빈과 마찬가지로 WebApplicationContext에서 설정할 수 있다. 이 빈들은 뒤에서 각각 자세히 설명한다. 지금은 DispatcherPortlet을 계속 설명하기 위해서 이러한 빈이 존재한다는 것만 알아두면 된다. 대부분의 빈은 설정을 신경쓰지 않아도 되도록 기본값을 제공한다.

Table 19.1. WebApplicationContext의 특수한 빈

표현식설명
handler mapping(s)(Section 19.5, “핸들러 매핑”) 전처리자, 후처리자, 컨트롤러의 목록으로 이들이 특정 크리테리아와 일치한다면 실행될 것이다.(예를 들어 찾아낸 포틀릿은 모드는 컨트롤러로 지정된다.)
controller(s)(Section 19.4, “컨트롤러”) MVC의 일부로 실제 기능을 제공하는 빈(또는 최소한 기능에 접근하는)
view resolver(Section 19.6, “뷰와 뷰 처리”) 뷰 이름을 뷰 정의로 처리할 수 있다
multipart resolver(Section 19.7, “멀티파트(파일 업로드) 지원”) HTML 폼의 파일 업로드를 처리하는 기능을 제공한다
handler exception resolver(Section 19.8, “예외 처리”) 예외를 뷰에 매핑하거나 복잡한 예외 처리코드를 구현하는 기능을 제공한다











DispatcherPortlet이 해당 DispatcherPortlet 들어오는 요청을 받고 사용할 설정이 되면 요청을 처리하기 시작한다. 아래 목록은 DispatcherPortlet의 요청을 처리하는 전체 과정을 설명한다.

  1. 요청을 처리할 때(뷰 렌더링, 데이터 준비 등) 처리중인 요청이 사용할 로케일을 처리하도록 PortletRequest.getLocale()가 반환하는 로케일을 요청에 바인딩한다.
  2. 멀티파트 리졸버를 지정했고 요청이 ActionRequest라면 해당 요청은 멀티파트인지 검사하고 멀티파트라면 다른 요소가 추가적인 처리를 하도록 MultipartActionRequest로 감싼다. (멀티파트 처리에 대한 자세한 내용은 Section 19.7, “멀티파트(파일 업로드) 지원”를 봐라.)
  3. 적합한 핸들러를 검색한다. 핸들러를 발견하면 모델을 준비하기 위해 핸들러(전처리자, 후처리자, 컨트롤러)에 연결된 실행 체인을 실행할 것이다.
  4. 모델이 반환되면 WebApplicationContext로 설정된 뷰 리졸버를 사용해서 뷰를 렌더링한다. 모델이 반환되지 않는다면(예를 들어 전처리자나 후처리자가 보안때문에 요청을 가로채는 등의 이유로) 요청이 이미 완료되었으므로 뷰를 렌더링하지 않는다.

요청을 처리하는 중 던저진 예외는 WebApplicationContext에 선언된 핸들러 예외 리졸버(handler exception resolver)가 처리한다. 이러한 예외 리졸버를 사용해서 예외가 던저진 경우에 대한 커스텀 동작을 정의할 수 있다.

portlet.xml 파일이나 포틀릿 init 파라미터에 컨텍스트 파라미터를 추가해서 스프링의 DispatcherPortlet를 커스터마이징할 수 있다. 할 수 있는 일은 다음 목록에 나와있다.

Table 19.2. DispatcherPortlet 초기화 파라미터

파라미터설명
contextClassWebApplicationContext를 구현한 클래스로 해당 포틀릿이 사용하는 컨텍스트를 인스턴스화하는데 사용할 것이다. 이 파라미터를 지정하지 않으면 XmlPortletApplicationContext를 사용할 것이다.
contextConfigLocation컨텍스트를 찾을 수 있는 위치를 나타내려고 컨텍스트 인스턴스 (contextClass가 지정한)에 전달하는 문자열이다. 이 문자열은 여러 컨텍스트(여러 컨텍스트 위치가 있는 경우 두번 정의된 빈은 마지막에 정의된 빈을 우선시한다)를 지원하기 위해 여러개의 문자열로 나눌 수 있다.(구분자로 콤마를 사용한다)
namespaceWebApplicationContext의 네임스페이스다. 기본값은 [portlet-name]-portlet이다.
viewRendererUrlDispatcherPortlet가 ViewRendererServlet에 접근할 수 있는 URL이다.(Section 19.3, “ViewRendererServlet” 참고)











19.3 ViewRendererServlet
포틀릿 MVC에서 렌더링 과정은 웹 MVC보다 약간 더 복잡하다. 스프링 웹 MVC의 모든 뷰 기술을 재사용하려면 PortletRequest / PortletResponse를 HttpServletRequest / HttpServletResponse로 변환하고 View의 render 메서드를 호출해야 한다. 이렇게 하기 위해서 DispatcherPortlet이 이 목적때문에 존재하는 전용 서블릿 ViewRendererServlet을 사용한다.

DispatcherPortlet 렌더링이 동작하려면 웹 어플리케이션의 web.xml 파일에 다음과 같이 ViewRendererServlet 인스턴스를 선언해야 한다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
Xml

<servlet>
  <servlet-name>ViewRendererServlet</servlet-name>
  <servlet-class>org.springframework.web.servlet.ViewRendererServlet</servlet-class>
</servlet>

<servlet-mapping>
  <servlet-name>ViewRendererServlet</servlet-name>
  <url-pattern>/WEB-INF/servlet/view</url-pattern>
</servlet-mapping>

실제 렌더링을 수행하기 위해 DispatcherPortlet는 다음의 과정을 진행한다.
  1. DispatcherServlet이 사용하는 같은 WEB_APPLICATION_CONTEXT_ATTRIBUTE 키에 속성으로 WebApplicationContext를 요청에 바인딩한다.
  2. ViewRendererServlet에서 사용할 수 있도록 Model과 View 객체를 요청에 바인딩한다.
  3. PortletRequestDispatcher를 생성하고 ViewRendererServlet에 매핑된 /WEB- INF/servlet/view URL을 사용해서 include를 수행한다.
그 다음 ViewRendererServlet이 View의 render 메서드를 적절한 인자로 호출할 수 있다.

ViewRendererServlet의 실제 URL은 DispatcherPortlet의 viewRendererUrl 설정 파라미터를 사용해서 변경할 수 있다.

19.4 컨트롤러
포틀릿 MVC의 컨트롤러는 웹 MVC 컨트롤러와 아주 유사하고 서로간에 코드를 포딩하는 것은 아주 간단하다.

포틀릿 MVC 컨트롤러 아키텍처의 기반은 다음 목록에 나온 org.springframework.web.portlet.mvc.Controller 인터페이스이다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
Java

public interface Controller {

  /**
   * 요청의 렌더링을 처리하고 DispatcherPortlet이 렌더링할
   * ModelAndView 객체를 반환한다.
   */
  ModelAndView handleRenderRequest(RenderRequest request, RenderResponse response)
    throws Exception;

  /**
   * 액션 요청을 처리한다. 아무것도 반환하지 않는다.
   */
  void handleActionRequest(ActionRequest request, ActionResponse response)
    throws Exception;
}

여기서 보듯이 포틀릿 Controller 인터페이스는 포틀릿 요청의 두 단계(액션 요청과 렌더링 요청)을 다루는 두 개의 메서드를 필요로 한다. 액션 단계는 액션 요청을 처리할 수 있어야 하고 렌더링 단계는 렌더링 요청을 처리하고 적절한 모델과 뷰를 반환할 수 있어야 한다. Controller 인터페이스가 상당히 추상화되어 있으므로 스프링 포틀릿 MVC는 필요로 할 많은 기능을 담고 있는 다수의 컨트롤러를 제공한다. 이러한 대부분의 컨트롤러는 스프링 웹 MVC의 컨트롤러와 아주 유사하다. Controller 인터페이스는 모든 컨트롤러가 필요로하는 많은 공통 기능(액션 요청, 렌더링 요청 처리, 모델과 뷰 반환)을 정의하고 있다.

19.4.1 AbstractController와 PortletContentGenerator
물론 Controller 인터페이스만으로는 충분치 않다. 기본 인프라스트럭처인 AbstractController를 상속받은 스프링 포틀릿 MVC의 모든 Controller를 제공하려면 클래스가 스프링의 ApplicationContext에 접근할 수 있고 캐싱을 제어할 수 있어야 한다.

Table 19.3. AbstractController가 제공하는 기능

파라미터설명
requireSession해당 Controller가 동작하는 세션을 필요로 하는지를 나타낸다. 이러한 컨트롤러가 요청을 받았을 때 세션이 제공되지 않으면 SessionRequiredException를 사용해서 사용자에게 알려준다.
synchronizeSession사용자 세션 동기화를 해당 컨트롤러가 제어하기를 원한다면 이 파라미터를 사용해라. 더 자세히 보자면 컨트롤러를 확장하는 것은 변수를 지정한 경우 사용자 세션의 동기화를 할 handleRenderRequestInternal(..)와 handleActionRequestInternal(..) 메서드를 오버라이드 할 것이다.
renderWhenMinimized포틀릿이 최소화된 상태(minimized state)일 때 컨트롤러가 뷰를 실제로 렌더링하게 하려면 이 파라미터를 true로 설정해라. 기본적으로 이는 false이므로 최소화된 상태의 포틀릿은 아무 내용도 보여주지 않을 것이다.
cacheSeconds포틀릿에 정의된 캐시 기본 만료(expiration)를 컨트롤러가 오버라이드하려면 이 파라미터를 양수로 지정해라. 기본적으로 이 파라미터는 기본 캐싱을 바꾸지 않는 의미로 -1로 설정되어 있다. 이 파라미터를 0으로 설정하면 결과를 절대 캐싱하지 않는다.













requireSession와 cacheSeconds 프로퍼티는 PortletContentGenerator (AbstractController의 수퍼클래스)에 선언하지만 자세함을 위해서 여기에 포함시켰다.

AbstractController를 컨트롤러의 기반클래스로 사용하는 경우(이미 해당 작업을 하는 다른 클래스가 많이 있으므로 추천하는 방법은 아니다.) handleActionRequestInternal(ActionRequest, ActionResponse) 메서드나 handleRenderRequestInternal(RenderRequest, RenderResponse) 메서드(혹은 둘다)를 오버라이드하고 로직을 구현하고 ModelAndView 객체를 반환 (handleRenderRequestInternal인 경우에)해야 한다.

handleActionRequestInternal(..)와 handleRenderRequestInternal(..)의 기본 구현체는 PortletException를 던진다. 이는 JSR-168 명세서 API의 GenericPortlet 동작과 일관성이 있다. 그러므로 컨트롤러가 다루기를 원하는 메서드만 오버라이드 해야한다.

클래스와 웹 어플리케이션 컨텍스트의 선언으로 구성된 간단한 예제가 다음에 나와 있다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Java

package samples;

import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;

import org.springframework.web.portlet.mvc.AbstractController;
import org.springframework.web.portlet.ModelAndView;

public class SampleController extends AbstractController {

    public ModelAndView handleRenderRequestInternal(RenderRequest request, RenderResponse response) {
        ModelAndView mav = new ModelAndView("foo");
        mav.addObject("message", "Hello World!");
        return mav;
    }
}


Xml

<bean id="sampleController" class="samples.SampleController">
  <property name="cacheSeconds" value="120"/>
</bean>

이 아주 간단한 컨트롤러가 동작하는데 위의 클래스와 웹 어플리케이션의 선언이 핸들러 매핑 구성(Section 19.5, “핸들러 매핑” 참고)외에 해야하는 전부이다.

19.4.2 그 외 간단한 컨트롤러
AbstractController를 확장할 수 있더라도 스프링 포틀릿 MVC는 간단한 MVC 어플리케이션에서 공통적으로 사용하는 기능을 제공하는 다수의 구현체를 제공하고 있다.

ParameterizableViewController는 웹 어플리케이션 컨텍스트에서 반환할 뷰 이름을 지정할 수 있다는 점(뷰 이름을 하드코딩할 필요가 없다)을 제외하면 기본적으로 위의 예제와 같다.

PortletModeNameViewController는 뷰 이름으로 포틀릿의 현재 모드를 사용한다. 그래서 포틀릿이 View 모드라면(예시: PortletMode.VIEW) 뷰 이름으로 "view"를 사용한다.

19.4.3 커맨드 컨트롤러
스프링 포틀릿 MVC는 스프링 웹 MVC와 정확히 같은 계층의 커맨트 컨트롤러를 가진다. 커맨드 컨트롤러는 데이터 객체와 상호작용하고 PortletRequest의 파라미터를 지정한 데이터 객체로 동적으로 바인딩하는 방법을 제공한다. 데이터 객체는 프레임워크에 특화된 인터페이스를 구현하지 않아야 하므로 원한다면 퍼시스턴트 객체를 직접 조작할 수 있다. 커맨드 컨트롤러로 무엇을 할 수 있는지 살펴보기 위해서 어떤 커맨드 컨트롤러를 사용할 수 있는지 보자.

  • AbstractCommandController - 자신만의 커맨트 컨트롤러를 생성하는데 사용할 수 있는 커맨드 컨트롤러로 요청 파라미터를 지정한 데이터 객체에 바인딩할 수 있다. 이 클래스는 폼(form) 기능을 제공하지 않지만 유효성검사 기능은 제공하고 컨트롤러에서 요청의 파라미터로 채워진 커맨드 객체로 무엇을 할지 지정하게 한다.
  • AbstractFormController - 폼 제출을 지원하는 추상 컨트롤러다. 이 컨트롤러를 사용해서 폼을 만들 수 있고 컨트롤러에서 획득한 커맨드 객체를 사용해서 폼을 유지할 수 있다. 사용자가 폼을 채운 후에 AbstractFormController가 필드를 바인딩하고 유효성을 검사하고 객체를 적절한 액션을 취하는 컨트롤러에 다시 전달한다. 유효하지 않은 폼 제출 (중복제출), 유효성 검사, 일반적인 폼 워크플로우의 기능을 지원한다. 폼 표현과 성공에 어떤 뷰를 사용할지 결정하는 메서드를 구현한다. 폼은 필요하지만 어플리케이션 컨텍스트에서 사용자를 보여줄 뷰를 지정하기 원치 않는다면 이 컨트롤러를 사용해라.
  • SimpleFormController - AbstractFormController의 구현체로 대응되는 커맨드 객체로 폼을 생성할 때 추가적인 지원을 제공한다. SimpleFormController는 커맨드 객체, 폼에 대한 뷰이름, 폼 제출이 성공적으로 이뤄졌을 때 사용자를 보여주는 페이지의 뷰이름을 지정하게 한다.
  • AbstractWizardFormController ? 여러 화면에 걸쳐서 커맨드 객체의 내용을 수정하는 마법사방식의 인터페이스를 제공하는 AbstractFormController의 구현체이다. 종료, 취소, 페이지 변경등 여러 사용자 동작을 지원하고 이 모든 기능을 화면의 요청 파라미터로 쉽게 지정한다.

이러한 커맨드 컨트롤러는 아주 강력하지만 효율적으로 사용하려면 어떻게 동작하는지 자세히 이해해야 한다. 이 컨트롤러의 전체 계층에 대해서는 Javadoc을 자세히 보고 사용하기 전에 예제 구현체를 살펴봐라.

19.4.4 PortletWrappingController
새로운 컨트롤러를 개발하는 대신 기존에 존재하는 포틀릿을 사용해서 DispatcherPortlet에서 요청을 컨트롤러로 매핑할 수 있다. PortletWrappingController를 사용해서 Controller로 이미 존재하는 Portlet을 다음과 같이 인스턴스화 할 수 있다.


1
2
3
4
5
6
7
8
9
Xml

<bean id="myPortlet" class="org.springframework.web.portlet.mvc.PortletWrappingController">
  <property name="portletClass" value="sample.MyPortlet"/>
  <property name="portletName" value="my-portlet"/>
  <property name="initParameters">
    <value>config=/WEB-INF/my-portlet-config.xml</value>
  </property>
</bean>

이러한 포틀릿으로 들어오는 요청 이전과 이후의 처리를 위해 인터셉터를 사용할 수 있으므로 이는 아주 가치가 있다. JSR-168가 필터 메카니즘을 전혀 지원하지 않으므로 이 방법이 아주 편리하다. 예를 들어 이를 MyFaces JSF 포틀릿을 하이버네이트 OpenSessionInViewInterceptor로 감싸는데 사용할 수 있다.

19.5 핸들러 매핑
핸들러 매핑을 사용해서 들어오는 포틀릿 요청을 적당한 핸들러로 매핑할 수 있다. 사용할 수 있는 몇몇 핸들러 매핑이 존재하지만(예를 들면 PortletModeHandlerMapping) 먼저 HandlerMapping의 일반적인 개념을 살펴보자.

Note: 의도적으로 “Controller” 대신에 “Handler”라는 용어를 여기서 사용하고 있다. DispatcherPortlet은 스프링 포틀릿 MVC 자체의 컨트롤러와는 다른 방법으로 요청을 처리하는데 사용하도록 설계되었다. 핸들러는 포틀릿 요청을 다룰 수 있는 객체이다. 컨트롤러는 핸들러의 하나의 예시이면서 기본값이다. 다른 프레임워크와 함께 DispatcherPortlet를 사용하려면 HandlerAdapter의 대응되는 구현체가 필요한 전부이다.

기본 HandlerMapping이 제공하는 기능은 들어오는 요청과 일치하는 핸들러를 반드시 가지고 요청에 적용되는 핸들러 인터셉터의 목록을 가질 수도 있는 HandlerExecutionChain의 전달이다. 요청이 들어올 때 DispatcherPortlet는 요청을 검사하고 적절한 HandlerExecutionChain에 접근하도록 핸들러 매핑에 전달한다. 그 다음 DispatcherPortlet은 체인에 있는(존재한다면) 핸들러와 인터셉터를 실행할 것이다. 이러한 개념은 스프링 웹 MVC와 완전히 같다.

선택적으로 인터셉터(실제 실행되는 핸들러 이전과 이후에 실행된다)를 가질 수 있고 설정가능한 핸들러 매핑의 개념은 굉장히 강력하다. 지원하는 다수의 기능은 커스텀 HandlerMapping의 일부가 될 수 있다. 들어오는 요청의 포틀릿 모드에 기반하지 않고 요청과 연관된 세션의 특정 상태에 기반해서 핸들러를 선택하는 커스텀 핸들러 매핑을 생각해 보자.

스프링 웹 MVC에서 핸들러 매핑은 일반적으로 URL에 기반한다. 포틀릿에서는 URL같은 것이 없기 때문에 매핑을 제어하는 다른 메카니즘을 사용해야 한다. 가장 일반적인 두가지는 포틀릿 모드와 요청 파라미터이지만 포틀릿 요청에서 사용할 수 있는 것들은 커스텀 핸들러 매핑에서도 사용할 수 있다.

이번 섹션의 남은 부분은 스프링 포틀릿 MVC에서 가장 일반적으로 사용하는 핸들러 매핑을 설명한다. 이 핸들러 매핑은 모두 AbstractHandlerMapping을 확장하고 다음 프로퍼티를 공유한다.

  • interceptors: 사용할 인터셉터 목록. HandlerInterceptor는 Section 19.5.4, “HandlerInterceptor 추가”에서 설명했다.
  • defaultHandler: 해당 핸들러 매핑에서 일치하는 핸들러가 없는 경우 사용할 기본 핸들러.
  • order: order 프로퍼티 값에 기반해서 (org.springframework.core.Ordered 인터페이스 참고) 스프링은 컨텍스트에서 사용할 수 있는 모든 핸들러 매핑을 정렬하고 처음 일치하는 핸들러를 적용할 것이다.
  • lazyInitHandlers: 싱글톤 핸들러의 지연 초기화를 허용한다.(프로토타입 핸들러는 항상 지연 초기화를 한다.) 기본값은 false다. 이 프로퍼티는 세가지 구현체에서 직접 구현되었다.

19.5.1 PortletModeHandlerMapping
들어오는 요청을 포틀릿의 현재 모드에 기반해서(예시. ‘view’, ‘edit’, ‘help’) 매핑하는 간단한 핸들러 매핑이다. 예를 들면 다음과 같다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
Xml

<bean class="org.springframework.web.portlet.handler.PortletModeHandlerMapping">
  <property name="portletModeMap">
    <map>
      <entry key="view" value-ref="viewHandler"/>
      <entry key="edit" value-ref="editHandler"/>
      <entry key="help" value-ref="helpHandler"/>
    </map>
  </property>
</bean>

19.5.2 ParameterHandlerMapping
포틀릿 모드를 변경하지 않고 여러 컨트롤러를 탐색해야 한다면 매핑을 제어하는 키로 요청 파라미터를 사용하는 것이 가장 간단한 방법이다.

ParameterHandlerMapping은 특정 요청 파라미터의 값을 매핑을 제어하는데 사용한다. 파라미터의 기본 이름은 'action'이지만 'parameterName' 프로퍼티를 사용해서 변경할 수 있다.

이 매핑에 대한 빈(bean) 설정은 다음과 같을 것이다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
Xml

<bean class="org.springframework.web.portlet.handler.ParameterHandlerMapping”>
  <property name="parameterMap">
    <map>
      <entry key="add" value-ref="addItemHandler"/>
      <entry key="edit" value-ref="editItemHandler"/>
      <entry key="delete" value-ref="deleteItemHandler"/>
    </map>
  </property>
</bean>

19.5.3 PortletModeParameterHandlerMapping
가장 강력한 내장 핸들러 매핑인 PortletModeParameterHandlerMapping는 각 포틀릿 모드내에서 다른 탐색을 허용하는 앞의 두 핸들러 매핑의 기능을 합쳐놓았다.

마찬가지로 기본 파라미터 이름은 "action"이지만 parameterName 프로퍼티를 사용해서 변경할 수 있다.

기본적으로 두가지 다른 포틀릿 모드에서 같은 파라미터값을 사용하지 않는다. 이는 포탈(portal)이 직접 포틀릿 모드를 변경하면 요청이 더이상 매핑에서 유효하지 않도록 하기 위함이다. 이 동작은 allowDupParameters 프로퍼티를 true로 설정해서 변경할 수 있다. 하지만 변경하는 것을 권장하지 않는다.

이 매핑에 대한 빈(bean) 설정은 다음과 같을 것이다.


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
Xml

<bean class="org.springframework.web.portlet.handler.PortletModeParameterHandlerMapping">
  <property name="portletModeParameterMap">
    <map>
      <entry key="view"> <!-- 'view' 포틀릿 모드 -->
        <map>
          <entry key="add" value-ref="addItemHandler"/>
          <entry key="edit" value-ref="editItemHandler"/>
          <entry key="delete" value-ref="deleteItemHandler"/>
        </map>
      </entry>
      <entry key="edit"> <!-- 'edit' 포틀릿 모드 -->
        <map>
          <entry key="prefs" value-ref="prefsHandler"/>
          <entry key="resetPrefs" value-ref="resetPrefsHandler"/>
        </map>
      </entry>
    </map>
  </property>
</bean>

이 매핑은 PortletModeHandlerMapping보다 먼저 체이닝될 수 있어서 각 모드나 전체적인 기본값을 제공할 수 있다.

19.5.4 HandlerInterceptor 추가
스프링의 핸들러 매핑 메카니즘은 특정 요청에 어떤 기능(예를 들어 중요한 검사 등)을 적용하기를 원할 때 아주 유용할 수 있는 핸들러 인터셉터의 개념을 가진다. 스프링 포틀릿 MVC는 웹 MVC와 같은 방법으로 이러한 개념을 구현한다.

핸들러 매핑에 있는 인터셉터는 org.springframework.web.portlet 패키지의 HandlerInterceptor를 구현해야 한다. 서블릿 버전처럼 이 인터셉터는 세가지 메서드를 정의한다. 한 메서드는 실제 핸들러가 실행되기 전에 호출될 것이고(preHandle) 한 메서드는 핸들러가 실행된 후에 호출할 것이고(postHandle) 한 메서드는 요청이 완료된 후에 호출할 것이다. (afterCompletion) 이 세가지 메서드는 모든 종류의 전처리와 후처리를 하는 유연성을 충분히 제공해야 한다.

preHandle 메서드는 불리언 값을 반환한다. 실행체인의 처리를 멈추거나 계속 진행하는데 이 메서드를 사용할 수 있다. 이 메서드가 true를 반환하면 핸들러 실행 체인을 계속 진행될 것이고 false를 반환하면 DispatcherPortlet는 인터셉터가 직접 요청을 처리한다고(예를 들어 적절한 뷰를 렌더링하는 등) 가정하고 실행 체인의 다른 인터셉터와 실제 핸들러를 계속해서 실행하지 않는다.

RenderRequest에서만 postHandle메서드를 호출한다. preHandle와 afterCompletion 메서드는 ActionRequest와 RenderRequest에서 모두 실행된다. 딱 한가지 종류의 요청에서 이러한 메서드의 로직을 실행해야 한다면 처리하기 전에 요청의 종류를 확인해봐야 한다.

19.5.5 HandlerInterceptorAdapter
서블릿 패키지처럼 포틀릿 패키지는 HandlerInterceptor의 구현체인 HandlerInterceptorAdapter를 가진다. 이 클래스를 상속받아서 필요한 하나나 두개의 메서드를 구현할 수 있도록 이 클래스는 구현부는 없는(empty)는 모든 메서드를 가진다.

19.5.6 ParameterMappingInterceptor
포틀릿 패키지도 ParameterMappingInterceptor라는 인터셉터를 가지므로 직접 ParameterHandlerMapping과 PortletModeParameterHandlerMapping을 함께 사용할 수 있다. 이 인터셉터는 파라미터를 ActionRequest에서 이어진 RenderRequest으로 진행하는 매핑을 제어하는데 사용할 수 있게 한다. 이는 ActionRequest처럼 RenderRequest가 같은 핸들러로 매핑된도록 보장하는 것을 도와줄 것이다. 이는 인터셉터의 preHandle 메서드에서 이뤄지므로 RenderRequest가 매핑될 위치를 변경하기 위해 핸들러에서 파라미터 값을 수정할 수 있다.

이 인터셉터가 ActionResponse에서 setRenderParameter를 호출하고 있음을 유의해라. 즉, 이 인터셉터를 사용할 때는 핸들러에서 sendRedirect를 호출할 수 없다. 외부로 리다이렉트해야 한다면 수동으로 파라미터를 매핑하거나 이를 처리하는 다른 인터셉터를 작성해야 할 것이다.