Servlet 3.1 동작 변경사항

Servlet 3.1 구현에는 Servlet 3.0에 대해 작성된 애플리케이션이 사용자가 Servlet 3.1 기능을 사용할 때 다르게 작동하거나 실패하게 하는 동작 변경사항이 포함되어 있습니다.

동작 변경사항을 고려하여 각 서버 인스턴스에 대해 Servlet 3.0 기능 구현과 Servlet 3.1 기능 구현 사이에서 선택할 수 있습니다. 필요한 동작이 Servlet 3.1 기능에만 포함되어 있는 경우에는 Servlet 3.1 기능을 사용해야 합니다. Servlet 3.1 기능의 동작 변경사항이 기존 애플리케이션에 부정적인 영향을 미치는 경우에는 Servlet 3.0 기능을 사용하면 해당 애플리케이션의 기존 동작이 유지됩니다. 동일한 서버에서 Servlet 3.0 기능과 Servlet 3.1 기능을 둘 다 사용할 수는 없습니다. 두 기능을 모두 구성하는 것은 오류입니다. 두 기능을 모두 구성하면 두 서블릿 기능 모두 로드되지 않습니다.

동작 변경사항은 세 가지 이유로 도입됩니다.

Servlet 3.1 스펙에서 명확성을 위해 필요한 변경사항
Servlet 3.1 구현이 Servlet 3.1 TCK(Technology Compatibility Kit)를 전달하기 위해 필요한 변경사항
서블릿 구현을 향상시키기 위한 변경사항

프로그래밍 방식으로 추가된 서블릿, 필터 및 리스너

이제 Servlet 3.1 스펙의 명확성으로 인해 ServletContextListener가 web.xml 파일 또는 web-fragment.xml 파일에서 선언되지 않았거나 @WebListener로 어노테이션 지정되지 않은 경우 ServletContextListener는 프로그래밍 방식으로 서블릿, 필터 또는 리스너를 구성할 수 없게 됩니다. 그 결과 이러한 프로그래밍 방식 구성을 수행하기 위한 ServletContext의 호출은 UnsupportedOperationException을 생성합니다.

비동기 처리가 시작된 후 전달

Servlet 3.0 구현에서는 RequestDispatcher 인터페이스의 전달 메소드가 리턴되기 전에 항상 응답이 닫힙니다. 하지만 Servlet 3.1 스펙에서의 명확성으로 인해 요청이 비동기 모드에 들어가는 경우 RequestDispatcher 인터페이스의 전달 메소드가 리턴되기 전에 Servlet 3.1 구현이 응답을 닫거나 비우지 않습니다. 이 변경사항은 기존 3.0 애플리케이션에 영향을 미치며 Servlet 3.0에서와는 달리 이제 이러한 응답 데이터가 전송되므로 전달로부터의 리턴 시 응답 출력을 추가합니다.

URL 패턴 충돌

Servlet 3.0에서 애플리케이션은 URL 패턴이 여러 서블릿에 맵핑된 경우에도 성공적으로 시작됩니다. 하지만 Servlet 3.1 스펙에서의 명확성으로 인해 애플리케이션은 시작하는 데 실패해야 합니다. Liberty Servlet 3.1 구현에서 메시지가 출력되고 응용 프로그램이 시작되지 않습니다

SRVE9016E: Unable to insert mapping [{0}] for servlet named [{1}]. The URL pattern is already defined for servlet named [{2}].

Explanation: There is an application error. A servlet mapping URL pattern should not map to multiple servlets.

User action: Change the URL pattern for the servlet mapping.

ServletContext.getMinorVersion()

Servlet 3.0 기능 구현에서 이 API는 0을 리턴합니다.

Servlet 3.1 기능에서 이 API는 이제 1을 리턴합니다.

ServletContext.getServerInfo()

Servlet 3.0 기능 구현에서 이 API는 SMF WebContainer을 리턴합니다.

서블릿 3.1 기능에서 이 API는 이제 IBM WebSphere Liberty/8.5.5.<x>를 리턴합니다. 여기서 < x> 는 WebSphere® Application Server 수정팩 번호입니다.

ServletResponse.reset()

응답이 아직 커미트되지 않은 경우 ServletResponse.reset()를 사용하여 모든 버퍼링된 응답 데이터, 상태 코드 및 응답 헤더를 지울 수 있습니다. Servlet 3.1 기능을 사용 중인 경우 이 메소드는 이전에 호출된 ServletResonse.getWriter() 또는 ServletResponse.getOutputStream()의 레코드도 모두 지웁니다.

X-Powered-By 헤더

Servlet 3.0 기능 구현에서는 X-Powered-By 헤더가 Servlet/3.0으로 설정됩니다. Servlet 3.1 기능 구현에서는 X-Powered-By 헤더가 Servlet/3.1로 설정됩니다.

자원 참조 인젝션 대상 병합

Servlet 3.0 스펙에서는 동일한 이름을 가진 web.xml 자원 참조 정의에 <injection-target> 요소가 없는 경우 web-fragment.xml 파일에서 정의되는 자원 참조의 <injection-target> 요소는 상위 web.xml 파일에만 추가됩니다. Servlet 3.1 스펙에서는 web-fragment.xml 디스크립터에 있는 모든 <injection-target> 요소가 동일한 이름의 자원 참조에 대한 <injection-target> 요소의 상위 web.xml 디스크립터 목록에 추가되는 것이 명확합니다. Servlet 3.1 기능이 사용 중인 경우 이 기능은 web.xml 파일에서 이전에 제외된 인젝션 대상을 활성화하여 기존 애플리케이션 기능을 변경합니다.

웹 디스크립터에서 중복 요소의 허용

Servlet 3.1 스펙에서는 web.xml 파일이 두 개의 <absolute-ordering> 요소를 포함할 수 없는 것이 명확했습니다. 여러 <absolute-ordering> 요소를 가진 애플리케이의 배치는 실패합니다. 또한 web-fragment.xml 디스크립터는 두 개의 <ordering> 요소를 포함할 수 없습니다. 여러 <ordering> 요소를 가진 애플리케이션의 배치는 실패합니다. 이전에는 배치가 실패하지 않았지만 요소의 기능이 불명확했습니다.

메타데이터 - 완료 케이스에서 웹 단편 순서 지정 변경

web.xml 디스크립터가 metadata-complete="true"로 표시된 경우에는 <absolute-ordering> 요소의 처리가 변경됩니다. 이전에 metadata-complete="true" 케이스에서는 모든 웹 단편 아카이브가 사용되었습니다. Servlet-3.1 기능을 사용 중인 경우 메타데이터-완료 케이스에서 <absolute-ordering> 요소는 완료된 것으로 간주됩니다. 이 변경으로 인해 <absolute-ordering> 요소에 나열되지 않는 단편이 처리에서 제외됩니다.

AsyncContext.dispatch()

AsyncContext.dispatch()가 사용되는 경우(예: 매개변수 없음) 요청은 원래 URL에 디스패치됩니다. Servlet-3.0 기능을 사용 중일 때 조회 문자열이 원래 요청과 함께 포함된 경우 이는 디스패치된 자원에 사용할 수 있게 됩니다. 하지만 Servlet 3.1 기능을 사용 중일 때 조회 문자열이 디스패치하는 자원에 제공된 경우 디스패치된 자원에 사용할 수 있게 되는 것은 이 조회 문자열입니다. 예를 들어,

Request for /FirstResource?param=One
First Resource:
    getParameter("param") returns "One"
           forward request to /SecondResource?param=Two
SecondResource
           getParameter(param) returns "Two"
           ac.start()
           ac.dispacth() dispatches to /FirstResource
First Resource
           Servlet-3.0 feature : getParamter("param") returns "One"
           Servlet-3.1 feature : getParameter("param") returns "Two"

This change was required by the Servlet 3.1 TCK.

AsyncContext.dispatch() 또는 AsyncContext.complete()가 허용되지 않은 이후 요청 또는 응답 오브젝트 가져오기는 결과적으로 다음 예외를 발생시킵니다.

java.lang.IllegalStateException: SRVE9015E: Cannot obtain the request or response object after an AsyncContext.dispatch() or AsyncContext.complete().
    at com.ibm.ws.webcontainer31.async.AsyncContext31Impl.getRequest(AsyncContext31Impl.java:72)
    [...]

SessionCookieConfig.setComment()

Java™ Servlet 3.1 Specification에 따르면, 이 API는 ServletContext 가 초기화를 완료한 후에 호출되면 illegalStateException 를 반환하고, Servlet 3.1 기능은 이 필수 동작을 따릅니다. 그러나 서블릿 3.0 기능은 컨텍스트가 초기화된 후에 이 API의 사용을 금지하지 않습니다. 따라서 서블릿 3.0 기능 동작에 의존하는 애플리케이션은 서블릿 기능 3.1 기능에서 작동하지 않습니다.

sendRedirect(java.lang.String location) API

sendRedirect(java.lang.String location) API는 상대 URL을 허용합니다. 그러나 서블릿 컨테이너는 클라이언트에 응답을 전송하기 전에 상대 URL을 절대 URL로 변환해야 합니다. 이 위치가 선행 '/'(folder/default.jsp)가 없는 상대 위치인 경우 컨테이너는 이를 현재 요청 URI에 상대적인 것으로 해석합니다. 이 위치가 선행 '/'가 있는 상대 위치인 경우에는 컨테이너가 이를 서블릿 컨테이너 루트에 상대적인 것으로 해석합니다.

예를 들어, 애플리케이션이 제공하는 리디렉션 위치가 folder/default.jsp 이고, 앞에 '/' 가 없고, 인바운드 요청이 URL 이고, http://host:port/context_root/folder 또는 http://host:port/context_root/folder/ 인 경우, 요청은 현재 요청 URI에 상대적인 http://host:port/context_root/folder/folder/default.jsp 로 리디렉션됩니다.

com.ibm.ws.webcontainer.redirectwithpathinfo 특성이 true로 설정된 경우에는 Servlet 3.0에서 이 동작이 수행됩니다. 설명된 바와 같이, 이 특성은 Servlet 3.1 기능에서 무시되며 동작이 기본값으로 설정됩니다.

기본 오류 페이지

IBM® 확장 기능은 웹 확장 (예: ibm-web-ext.xml) 을 사용하여 기본 오류 페이지를 지정하는 기능입니다.

Servlet 3.0 이상의 기능으로서 기본 오류 페이지는 오류 페이지를 지정하는 기능이 수정된 것입니다. 일반적인(기본이 아닌) 오류 페이지와 마찬가지로 기본 오류 페이지는 웹 모듈 디스크립터(web.xml)와 웹 단편 디스크립터(web-fragment.xml)에서 지정됩니다.

일반적인(기본이 아닌) 오류 페이지는 예외 유형 또는 오류 코드를 지정합니다. 기본 오류 페이지는 예외 유형과 오류 코드를 모두 생략합니다. 기본 오류 페이지는 서블릿이 예외를 발행하거나 오류 코드 결과를 설정하며 예외의 유형과 일치하거나 설정된 오류 코드와 일치하는 구성된 오류 페이지가 없는 경우 사용됩니다.

기본 오류 페이지를 정의하는 기능은 Servlet 3.0 스펙에 의해 제공되며 Servlet 3.0 스키마에 의해 지원됩니다. 기본 오류 페이지는 Servlet 3.1 스펙에 따라 exception-type 또는 error-code 요소를 포함하고 있지 않은 오류 페이지입니다.

오류 페이지 및 기본 오류 페이지의 예가 뒤따라옵니다.

기본 오류 페이지 서열 규칙

web.xml, web-fragment.xml 및 ibm-web-ext.xml 파일에 있는 기본 오류 페이지의 우선순위를 판별하기 위해 세 가지 규칙이 적용됩니다.

규칙 1: web.xml 및 web-fragment.xml 파일.
기본 오류 페이지는 web.xml 파일에서 지정되면 web-fragment.xml 파일에서 지정되는 기본 오류 페이지를 모두 대체(마스크)합니다. 또한 여러 web-fragment.xml 파일이 기본 오류 페이지를 지정하는 경우 오류가 없습니다.
규칙 2: web-fragment.xml 및 web-fragment.xml.
기본 오류 페이지가 web.xml 파일에서 지정되면 둘 이상의 web-fragment.xml 파일에 의해 서로 다른 기본 오류 페이지가 지정되는 경우 오류 조건이 존재합니다.
규칙 3: ibm-web-ext.xml 및 web.xml 또는 web-fragment.xml 파일.
ibm-web-ext.xml 파일과 web.xml 또는 web-fragment.xml 파일 간 우선순위의 규칙은 웹 컨테이너 기능 레벨에 따라 다릅니다.

웹 컨테이너 기능 레벨이 3.0이면 ibm-web-ext.xml 파일에 의해 정의되는 기본 오류 페이지가 web.xml 또는 web-fragment.xml 파일에서 정의되는 기본 오류 페이지보다 우선합니다.

참고: 웹 컨테이너가 기능 레벨 3.0을 사용하는 경우 서블릿 3.1 스키마를 사용할 수 없습니다. Servlet 3.0 스키마에 대해 기본 오류 페이지 사용에 대한 규칙을 참조하십시오.

웹 컨테이너 기능 레벨이 3.1 이상이면 web.xml 또는 web-fragment.xml 파일에 의해 지정되는 기본 오류 페이지가 ibm-web-ext.xml 파일에서 지정되는 기본 오류 페이지보다 우선합니다.

스키마 규칙

기본 오류 페이지가 web.xml 파일과 web-fragment.xml 파일 중 어느 파일에서 처리되는지에 대해 두 가지 규칙이 적용됩니다. 규칙은 웹 컨테이너 기능 버전, 사용 중인 서블릿 스키마 및 Java 사용자 정의 특성의 설정에 따라 다릅니다.

이러한 규칙은 IBM WebSphere Application Server traditional V8.0이 V8.0 GA (General Availability) 릴리스에서 기본 오류 페이지를 지원하지 않기 때문에 발생했습니다. APAR PM94199가 기본 오류 페이지에 대한 지원을 서비스 팩으로 WebSphere Application Server Traditional에 추가했습니다. 기본 오류 페이지에 대한 지원이 APAR PI05845에 의해 서비스 팩의 Liberty 에 추가되었습니다. 이러한 업데이트는 외부에서 볼 수 있는 기능의 변경이므로 새 기능은 기본적으로 사용 안함으로 설정되며 Java 시스템 특성에 의해 사용으로 설정되어야 합니다.

규칙 1: Servlet 3.0 스키마와 웹 컨테이너 기능 버전 3.0을 사용하는 기본 오류 페이지.
웹 컨테이너 기능 버전이 3.0 이고 기본 오류 페이지가 서블릿 3.0 스키마를 사용하는 web.xml 또는 web-fragment.xml 파일에 지정된 경우, 기본 오류 페이지는 com.ibm.ws.webcontainer.allowdefaulterrorpage Java 시스템 특성이 true로 설정된 경우에만 처리됩니다. Java 시스템 특성이 설정되지 않았거나 true로 설정되지 않은 경우 기본 오류 페이지가 무시됩니다. ibm-web-ext.xml 파일에 의해 지정되는 기본 오류 페이지가 사용됩니다.
케이스 2: 웹 컨테이너 기능 버전 3.1을 사용하는 기본 오류 페이지.
웹 컨테이너 기능 버전이 3.1 이상인 경우, 사용되는 서블릿 스키마 버전 및 Java 사용자 정의 특성이 설정되었는지 여부에 관계없이 web.xml 파일 또는 web-fragment.xml 파일에 지정된 기본 오류 페이지가 항상 처리됩니다.

Servlet 3.1 스키마를 사용하는 디스크립터를 처리하려면 웹 컨테이너 기능 버전 3.1이 필요하므로 디스크립터가 Servlet 3.1 스키마를 사용하는 경우 이 케이스가 발생합니다.

주의: 웹 단편은 Servlet 3.0까지 추가되지 않았습니다. web-fragment.xml 파일에는 Servlet 2.5의 스키마가 없습니다.

오류 페이지 및 기본 오류 페이지 예

ibm-web-ext.xml 파일에서 정의되는 기본 오류 페이지:

<?xml version="1.0" encoding="UTF-8"?>
<web-ext xmlns="http://websphere.ibm.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-web-ext_1_0.xsd"
    version="1.0">

	<default-error-page uri="/ExtErrorPage.html"/>
</web-ext>

web.xml 파일 또는 web-fragment.xml 파일에서 정의되는 오류 코드 오류 페이지 요소:

<error-page>
		<error-code>404</error-code>
			<location>/ErrorCodeErrorPage.html</location>
</error-page>

web.xml 파일 또는 web-fragment.xml 파일에서 정의되는 예외 유형 오류 페이지 요소:

<error-page>
		<exception-type>javax.servlet.ServletException</exception-type>
		<location>/ExceptionTypeErrorPage.html</location>
</error-page>

web.xml 파일 또는 web-fragment.xml 파일에서 정의되는 기본 오류 페이지 요소:

<error-page>
		<location>/DefaultErrorPage.html</location>
</error-page>

스키마 예

Servlet 2.5 스키마를 사용하는 web.xml 파일의 예제 헤더:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
		 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
      version="2.5">

Servlet 3.0 스키마를 사용하는 web.xml 파일의 예제 헤더:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
      version="3.0">

Servlet 3.1 스키마를 사용하는 web.xml 파일의 예제 헤더:

<?xml version="1.0" encoding="UTF-8"?>
<web-app
    xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
    version="3.1">

Servlet 3.0 스키마를 사용하는 web-fragment.xml 파일의 예제 헤더:

<?xml version="1.0" encoding="utf-8"?>
<web-fragment xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-fragment_3_0.xsd"
      version="3.0">

Servlet 3.1 스키마를 사용하는 web-fragment.xml 파일의 예제 헤더:

<?xml version="1.0" encoding="utf-8"?>
<web-fragment xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns="http://xmlns.jcp.org/xml/ns/javaee"
      xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-fragment_3_1.xsd"
      version="3.1">