Sun Java System Application Server 9.1 Update 1-9.1 Update 2 릴리스 노트

웹 컨테이너

이 절에서는 웹 컨테이너와 관련된 알려진 문제점과 해결 방법을 설명합니다.

Windows에서 --precompilejsp=true를 사용하여 응용 프로그램을 배포하면 JAR 파일이 응용 프로그램 내에서 잠겨 이후의 배포 해제나 재배포가 실패할 수 있음(5004315)

설명

Windows에서 응용 프로그램을 배포할 때 JSP의 사전 컴파일을 요청하고 나중에 해당 응용 프로그램의 배포를 해제하거나 해당 응용 프로그램(또는 동일한 모듈 아이디를 가진 응용 프로그램)을 재배포하려고 시도하면 예상한 것처럼 작동하지 않습니다. 문제는 JSP 사전 컴파일을 수행하면 응용 프로그램의 JAR 파일을 열지만 닫지 않고 Windows에서는 배포 해제 시 그러한 파일을 삭제하지 못하거나 재배포 시 덮어쓰지 못합니다.

배포 해제는 응용 프로그램이 Application Server에서 논리적으로 제거된다는 점에서 어느 정도는 성공한 것으로 볼 수 있습니다. 또한 asadmin 유틸리티는 오류 메시지를 반환하지 않지만 응용 프로그램의 디렉토리와 잠긴 jar 파일은 서버에 남아 있습니다. 서버의 로그 파일에는 파일 및 응용 프로그램 디렉토리를 삭제하는 데 실패한 것을 설명하는 메시지가 포함됩니다.

배포 해제에 실패한 후 응용 프로그램을 재배포하려는 시도는 서버에서 기존 파일과 디렉토리를 제거하려고 하기 때문에 역시 실패하게 됩니다. 이러한 문제는 원래 배포한 응용 프로그램과 동일한 모듈 아이디를 사용하는 응용 프로그램을 배포하려고 시도하면 서버가 응용 프로그램 파일을 저장할 디렉토리 이름을 선택할 때 모듈 아이디를 사용하기 때문에 발생할 수 있습니다.

먼저 응용 프로그램의 배포를 해제하지 않고 재배포하려고 시도하는 경우도 같은 이유 때문에 실패합니다.

진단

응용 프로그램의 배포를 해제한 후 재배포하려고 시도하면 asadmin 유틸리티는 아래와 유사한 오류를 반환합니다.


An exception occurred while running the command. The exception 
message is: CLI171 Command deploy failed : Deploying application in 
domain failed; Cannot deploy. Module directory is locked and can't 
be deleted.

해결 방법

응용 프로그램을 배포할 때 --precompilejsps=false(기본 설정)를 지정한 경우에는 이 문제가 발생하지 않습니다. 응용 프로그램을 처음 사용하면 JSP 컴파일이 트리거되어 첫 번째 요청에 대한 응답 시간은 이후의 요청에 대한 응답 시간보다 더 깁니다.

사전 컴파일을 수행하면 응용 프로그램을 배포 해제 또는 재배포하기 전에 서버를 중단하고 다시 시작해야 합니다. 서버를 종료하면 잠긴 JAR 파일의 잠금이 해제되어 재시작한 후 배포 해제 또는 재배포를 성공적으로 수행할 수 있습니다.

<load-on-startup> 요소가 포함된 Servlet 2.4 기반 web.xml로 WAR을 배포할 수 없음(6172006)

설명

web.xml 파일에서 선택 요소인 load-on-startup 서블릿 요소는 연관된 서블릿이 선언된 웹 응용 프로그램 시작의 일부로 로드되고 초기화된다는 것을 나타냅니다.

이 요소의 옵션 부분은 서블릿이 웹 응용 프로그램의 다른 서블릿과 관련하여 로드되고 초기화되는 순서를 나타내는 정수입니다. <load-on-startup> 요소가 비어 있으면 서블릿이 웹 응용 프로그램을 포함하는 시작 중에 로드되고 초기화되는 한 순서는 상관이 없음을 의미합니다.

web.xml을 위한 Servlet 2.4 스키마는 더 이상 빈 <load-on-startup>을 지원하지 않습니다. 즉, Servlet 2.4 기반 web.xml을 사용할 때 정수를 지정해야 합니다. <load-on-startup>과 같이 빈 <load-on-startup/>을 지정하면 web.xmlweb.xml을 위한 Servlet 2.4 스키마에 대한 검증에 실패하며 이로 인해 웹 응용 프로그램 배포에 실패하게 됩니다.

역호환성 문제로 빈 <load-on-startup>을 지정해도 Servlet 2.3 기반의 web.xml과는 아무 문제 없이 작동합니다.

해결 방법

Servlet 2.4 기반 web.xml을 사용하여 서블릿 로드 순서가 중요하지 않다는 것을 나타낼 때 <load-on-startup>0</load-on-startup>을 지정합니다.

자원이 제약된 서버에서 JSP 페이지를 컴파일할 수 없음(6184122)

설명

JSP 페이지에 액세스하지만 컴파일에 실패하고 서버 로그에는 다음과 같은 스택 추적과 함께 "Unable to execute command"라는 오류 메시지가 포함됩니다.


at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.
exec(Execute.java:655) at org.apache.tools.ant.taskdefs.Execute.
launch(Execute.java:416) 
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:427) 
at org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.
executeExternalCompile(DefaultCompilerAdapter.java:448) 
at org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute
(JavacExternal.java:81) 
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842) 
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682) 
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:396)

해결 방법

JSP 컴파일 스위치인 "fork"를 "false"로 설정합니다.

이 작업은 다음 중 한 가지 방법으로 수행할 수 있습니다.

어떤 방법으로 설정하든 ant에서 javac 컴파일을 위한 새로운 프로세스를 생성하지 못하도록 합니다.

응용 프로그램 서버에서 auth-passthrough Web Server 6.1 Add-On을 지원하지 않음(6188932)

설명

Sun Java System Application Server 9.1 Update 1에서는 Sun Java System Application Server Enterprise Edition 7.1에서 사용할 수 있는 auth-passthrough 플러그인 기능을 통해 제공되는 기능의 지원을 추가합니다. 하지만 Application Server 9.1 Update 1에서는 auth-passthrough 플러그인 기능이 다르게 구성됩니다.

Application Server Enterprise Edition 7.1의 auth-passthrough 플러그인 기능은 다음과 같은 2계층 배포 시나리오에서 유용하게 사용됩니다.

이러한 네트워크 아키텍처에서 클라이언트는 프런트엔드 웹 서버에 연결됩니다. 이 웹 서버는 service-passthrough 플러그인 함수로 구성되어 있으며 프록시를 거친 Application Server 인스턴스에 처리하도록 HTTP 요청을 전달합니다. Application Server 인스턴스는 웹 서버 프록시의 요청만을 받을 수 있는데 클라이언트 호스트로부터는 직접 받지 못합니다. 결과적으로, 클라이언트의 IP 주소 같은 클라이언트 정보를 쿼리하는 프록시를 거친 Application Server 인스턴스에 배포된 응용 프로그램은 프록시 호스트 IP를 받습니다. 이것이 전달된 요청의 실질적인 보낸 호스트이기 때문입니다.

해결 방법

Application Server Enterprise Edition 7.1에서는 auth-passthrough 플러그인 기능을 프록시가 지정된 Application Server 인스턴스에 구성하여 원격 클라이언트의 정보를 배포된 모든 응용 프로그램에서 직접 사용할 수 있게 만들 수 있습니다. 작업은 service-passthrough 플러그인을 실행하는 중간 웹 서버 대신 프록시가 지정되어 있는 Application Server 인스턴스에서 요청을 직접 받은 것처럼 수행됩니다.

Application Server 9.1 Update 1에서 auth-passthrough 기능은 다음과 같이 domain.xml에 있는 <http-service> 요소의 authPassthroughEnabled 등록 정보를 TRUE로 설정하여 활성화합니다.


<property name="authPassthroughEnabled" value="true"/>

Application Server Enterprise Edition 7.1에 있는 auth-passthrough 플러그인 기능의 같은 보안 고려 사항이 Application Server 9.1 Update 1에 있는 authPassthroughEnabled 등록 정보에도 적용됩니다. authPassthroughEnabled를 사용하면 인증 목적으로 사용되는 정보(요청이 전송된 IP 주소 또는 SSL 클라이언트 인증서)를 대체할 수 있기 때문에 authPassthroughEnabled가 TRUE로 설정된 Application Server 9.1 Update 1 인스턴스에는 신뢰할 수 있는 클라이언트 또는 서버의 연결만 허용해야 합니다. 더욱 주의하는 의미에서 회사 방화벽 뒤의 서버에서만 authPassthroughEnabled를 TRUE로 설정하여 구성하는 것이 좋습니다. 인터넷을 통해 액세스할 수 있는 서버는 authPassthroughEnabled를 TRUE로 설정하여 구성해서는 안 됩니다.

프록시 웹 서버가 service-passthrough 플러그인으로 구성되어 있고 authPassthroughEnabled가 TRUE로 설정된 Application Server 8.1 Update 2 인스턴스에 요청을 전달하는 시나리오에서 SSL 클라이언트 인증은 웹 서버 프록시에서 활성화될 수 있으며 프록시를 거친 Application Server 8.1 Update 2 인스턴스에서는 비활성화됩니다. 이 경우 프록시를 거친 Application Server 8.1 Update 2 인스턴스는 마치 SSL을 통해 인증된 것처럼 요청을 취급하고 클라이언트의 SSL 인증서를 요청하는 배포된 응용 프로그램에 해당 인증서를 제공합니다.