test

Sun Java System Application Server Enterprise Edition 8.2 Microsoft Windows용 릴리스 노트

웹 컨테이너

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

로드 밸런서 플러그인에 Apache 및 IIS 지원 없음

Sun Java ES 5 Application Server에서는 로그 밸런서 플러그인에 대해 Apache 및 IIS(비Sun 웹 컨테이너)를 지원하지 않습니다. Sun Java ES는 로드 밸런서 플러그인 구성을 위해 Sun Java System Web Server를 설치합니다.

--precompilejsp=true를 사용하여 응용 프로그램을 배포하면 JAR 파일이 잠길 수 있음(ID 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 파일의 잠금이 해제되어 재시작한 후 배포 해제 또는 재배포를 성공적으로 수행할 수 있습니다.

WAR를 빈 <load-on-startup> 요소가 있는 Servlet 2.4 기반 web.xml과 함께 배포할 수 없음(ID 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.xml은 web.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 페이지를 컴파일할 수 없음(ID 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 컴파일을 위한 새 프로세스를 생성하지 못하게 됩니다.

Application Server가 auth-passthrough Web Server 6.1 Add-On을 지원하지 않음(ID 6188932)

Sun Java System Application Server Enterprise Edition 8.2는 Sun Java System Application Server Enterprise Edition 7.1에서 사용할 수 있는 auth-passthrough 플러그인 함수가 제공하는 기능을 추가로 지원합니다. 하지만 Application Server Enterprise Edition 8.2에서 auth-passthrough 플러그인 기능은 다르게 구성됩니다.

Application Server Enterprise Edition 7.1에서 auth-passthrough 플러그인 함수는 다음 조건일 경우 2계층 배포 시나리오에 사용할 수 있었습니다.

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

Application Server Enterprise Edition 7.1에서 auth-passthrough 플러그인 함수는 프록시를 거친 Application Server 인스턴스에서 구성될 수 있습니다. 이는 service-passthrough 플러그인을 실행 중인 중간 웹 서버를 통하지 않고 프록시를 거친 Application Server 인스턴스가 요청을 직접 받을 수 있는 것과 마찬가지로 이 인스턴스에 배포되어 있는 응용 프로그램에서 직접 원격 클라이언트의 정보를 사용할 수 있도록 하기 위해서입니다.

Application Server Enterprise Edition 8.2에서 auth-passthrough 기능은 다음과 같이 domain.xml의 <http-service> 요소의 authPassthroughEnabled 등록 정보를 TRUE로 설정하여 사용할 수 있습니다.


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

Application Server Enterprise Edition 7.1에서 auth-passthrough 플러그인 함수의 동일한 보안 고려 사항은Application Server Enterprise Edition 8.2의 authPassthroughEnabled 등록 정보에도 적용됩니다. authPassthroughEnabled를 사용하면 인증 목적으로 사용할 수 있는 정보(요청을 보낸 IP 주소 또는 SSL 클라이언트 인증서 등)를 대체할 수 있습니다. 따라서 트러스트된 클라이언트 또는 서버에만 Application Server Enterprise Edition 8.2 인스턴스 연결이 허용되도록 authPassthroughEnabled를 TRUE로 설정해야 합니다. 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 인증서를 요청하는 배포된 응용 프로그램에 해당 인증서를 제공합니다.

--enabled=false를 사용하여 만든 HTTP 수신기는 수신기를 비활성화할 수 없음(ID 6190900)

--enabled=false 플래그를 사용하여 httplistener를 만들 경우 해당 수신기가 비활성화되지 않습니다. --enabled 플래그는 수신기를 만드는 동시에 사용되는 경우에는 적용되지 않습니다.

해결 방법

수신기를 활성 상태에서 만든 다음 나중에 수동으로 비활성화합니다.