이 장에서는 Sun Java System Application Server Platform Edition 8.2 제품의 알려진 문제점과 이를 해결하는 방법에 대해 설명합니다. 문제를 설명하는 부분에서 특정 플랫폼을 언급하지 않는 경우에는 해당 문제가 모든 플랫폼에 적용됩니다. 이 정보는 다음 내용으로 구성되어 있습니다.
기본적으로 $INSTALL/lib/package-appclient.xml에는 asenv.conf 파일이 가리키는 domain1의 AS_ACC_CONFIG 변수를 위한 하드 코드된 값이 있습니다. domain1이 삭제되고 새 도메인이 만들어지는 경우 AS_ACC_CONFIG 변수가 새 도메인 이름으로 업데이트되지 않아 package-appclient 스크립트 실패 요인이 됩니다.
다음 중 한 가지를 수행합니다.
domain1을 그대로 두고 그 주위에 다른 도메인을 만듭니다.
domain1을 제거하고 $INSTALL/lib/package-appclient.xml에서 domain1의 하드 코드된 값을 새 도메인 이름으로 변경합니다. domain1이 없는 경우에는 새 도메인이 생성될 때마다 이 작업을 수행해야 합니다.
asadmin restore-domain 명령은 도메인 이름 변경 옵션을 제공하지만 원래 이름과 다른 이름을 사용하여 도메인을 복원할 수 없기 때문에 backup-domain 명령과 restore-domain 명령을 사용하여 동일한 Application Server 설치에서 도메인 미러링을 수행할 수 없습니다. 백업한 도메인의 이름을 변경하는 데 성공한 것처럼 보이지만 이름을 변경한 도메인을 시작하려고 시도하면 도메인 구성의 항목이 변경되지 않고 startserv 및 stopserv가 원래 도메인 이름을 사용하여 경로를 설정하기 때문에 실패하게 됩니다.
restore-domain 명령에 사용된 도메인 이름이 원래 backup-domain 명령에 사용된 이름과 같아야 합니다. Application Server 8.2의 backup-domain 및 restore-domain 명령은 같은 시스템의 동일한 도메인을 백업하고 복원하는 경우에만 사용할 수 있습니다.
J2SE 1.4.x, 5.0 이상을 Application Server에서 구성할 수 있습니다. J2SE 5.0 플랫폼의 중요한 기능은 JMX 에이전트를 시작하는 것입니다. 이 기능은 서버를 시작할 때 시스템 등록 정보를 명시적으로 설정하면 활성화됩니다.
예를 들면 다음과 같습니다.
name="com.sun.management.jmxremote" value="true" name="com.sun.management.jmxremote.port" value="9999" name="com.sun.management.jmxremote.authenticate" value="false" name="com.sun.management.jmxremote.ssl" value="false"
JMX 등록 정보를 구성하고 서버를 시작한 후 새 jmx-connector 서버가 Application Server VM 내에서 시작됩니다. 이로 인한 원하지 않는 부작용으로 관리 기능이 역으로 영향을 받고 Application Server 관리 GUI 및 CLI에서 예기치 못한 결과가 발생할 수 있습니다. 문제는 기본 제공의 jmx-connector 서버와 새 jmx-connector 서버 사이에 충돌이 발생하는 것입니다.
jconsole(또는 다른 JMX 호환 클라이언트)을 사용할 경우 Application Server 시작과 함께 시작되는 표준 JMX Connector Server를 다시 사용할 것을 고려합니다.
서버를 시작하면 아래에서 설명한 것과 유사한 행이 server.log에 표시됩니다. 그곳에 지정된 JMXServiceURL에 연결하여 자격 증명을 성공적으로 제공한 후 동일한 관리/구성 작업을 수행할 수 있습니다. 예를 들면 다음과 같습니다.
[#|2004-11-24T17:49:08.203-0800|INFO|sun-appserver-ee8.1|javax.enterprise. system.tools.admin|_ThreadID=10;|ADM1501: Here is the JMXServiceURL for the JMXConnectorServer: [service:jmx:rmi:///jndi/rmi://hostname:8686/management/ rmi-jmx-connector]. This is where the remote administrative clients should connect using the JSR 160 JMX Connectors.|#]
자세한 내용은 Sun Java System Application Server 8.2 Administration Guide를 참조하십시오.
웹 모듈이 가상 서버의 기본 웹 모듈로 지정되어 있는 경우 해당 웹 모듈을 재배포하거나 배포 해제하면 다음과 같은 오류가 발생합니다.
Trying to undeploy application from domain failed; Virtual Servers [server] have <WEB-MODULE-NAME\> as default web module. Please remove the default web module references first. ; requested operation cannot be completed Virtual Servers [server] have <WEB-MODULE-NAME\> as default web module. Please remove the default web module references first.
이 때 domain.xml은 오류 상태이며 관리 콘솔은 배포된 웹 응용 프로그램을 보여주는 테이블을 표시하지 못할 수 있습니다. 도메인이 중지된 후 다시 시작되는 경우에도 이 상태가 지속됩니다.
기본 웹 모듈을 변경합니다.
관리 콘솔을 사용하여 가상 서버 페이지로 이동한 다음 기본 웹 모듈을 변경하여 비워두거나 다른 웹 모듈을 지정합니다.
CLI를 사용하여 domain을 대상으로 지정함으로써 웹 모듈을 배포 해제합니다.
# asadmin undeploy --target domain <WEB-MODULE-NAME\> |
이제 관리 콘솔이 정상적으로 작동합니다. 원하는 경우 웹 모듈을 재배포할 수 있습니다.
AMX API를 사용하여 PE에서 응용 프로그램을 배포한 후 참조하지 않을 경우 Application Server GUI는 해당 응용 프로그램을 표시하는 동안 오류를 발생시킵니다. AMX를 사용하려면 응용 프로그램에 대한 참조를 명시적으로 처리해야 합니다. 예를 들어, 응용 프로그램이 배포될 때 DeployedItemRefConfig를 명시적으로 만들어야 합니다. 배포 프로세스를 단순화하기 위해 PE에 참조가 있는 것으로 가정하는데, 여기서 Application Server GUI에 관한 문제가 발생합니다.
자원 또는 응용 프로그램을 만든 후 항상 해당 참조를 만듭니다.
Application Server 도메인/서버가 연결된 구성의 java-config 요소에 대한 java-home 속성에 지정된 JDK를 사용하지 않습니다.
지정된 서버 설치에서 모든 도메인의 Application Server 프로세스에 사용되는 JDK는 appserver-installation-dir /config/asenv.conf 파일에서 결정됩니다. 이 파일의 AS_JAVA 등록 정보는 사용되는 JDK를 결정하며 설치 시에 설정됩니다. 설치가 완료된 후에 Application Server 프로세스에서 다른 JDK를 사용하려면 이 값을 다른 JDK로 수정할 수 있습니다. 이 설치에 있는 모든 도메인은 이 변경의 영향을 받습니다.
asenv.conf 파일을 수동으로 변경할 경우 유효성이 검사되지 않으므로 주의해야 합니다. AS_JAVA 값을 수정할 때의 최소 JDK 버전 요구 사항은 제품 설명서를 참조하십시오.
현재 JDK 코드에서 /dev/poll 선택기는 사용할 8192 pollfd 항목 배열을 할당합니다. 이 값이 nofiles ulimit을 초과하여 "잘못된 인수" 오류가 발생하고 실패합니다. 그러면 selector.select()가 손상되기 때문에 시작하는 동안 MQ에 연결하는 Application Server 소켓 서비스가 실패하고 IOException이 발생합니다.
pollfd 파일 설명자 제한을 늘립니다. 이 작업은 다음과 같은 두 가지 방법으로 수행할 수 있습니다.
쉘에서 ulimit -n 8193을 루트로 실행합니다.
파일 설명자 수에 대한 하드 제한을 8193 이상으로 늘립니다.
ulimit -n -H를 사용하여 하드 제한을 확인합니다.
8193보다 작을 경우 /etc/system을 편집하여 set rlim_fd_max=8193 명령을 추가합니다.
시스템을 재부트합니다.
도메인의 마스터 비밀번호에 백분율(%) 문자가 있는 경우 도메인이 시작되지 않습니다.
도메인의 마스터 비밀번호에는 백분율 문자(%)를 사용할 수 없습니다. 이 사항은 새 도메인을 만들거나 기존 도메인의 마스터 비밀번호를 변경할 때 적용됩니다.
JVM 프록시 설정에 다음을 추가하면 서버가 시작되지 않습니다.
<jvm—options>-Dhttp.proxyHost=webcache.east.sun.com</jvm—options> <jvm—options> -Dhttp.proxyPort=8080</jvm—options> <jvm—options>-Dhttp.nonProxyHosts="mssp.ctu.gov|*.ctu.gov|localhost" </jvm—options> |
* 문자를 삽입하면 No Class Def Found 오류(main java.lang.NoClassDefFoundError: com/sun/enterprise/security/store/IdentityManager 스레드의 예외)가 발생합니다. | 문자를 삽입하면 서버의 시작을 기다리는 동안 시작 스크립트가 시간 초과됩니다.
방화벽 뒤에 있으며 외부 서버와 내부 서버 모두에 액세스해야 하는 Application Server 배포(및 포털 배포)를 지원하려면 이 기능이 필수적입니다. 예를 들면 Portal Server URL 스크레이퍼가 있습니다. URL 스크레이퍼가 외부 소스의 내용을 가져오려면 이러한 설정이 필요합니다.
install-dir/config/asenv.conf 파일을 편집하여 AS_NATIVE_LAUNCHER="true" 행을 AS_NATIVE_LAUNCHER="false"로 변경합니다.
이 절에서는 응용 프로그램 클라이언트와 관련된 알려진 문제점과 해결 방법을 설명합니다.
클라이언트 JAR 내에 최상위 JAR 파일이 있는 경우(이 경우에는 reporter.jar) 클라이언트 JAR을 배포할 때 해당 JAR의 MANIFEST 파일이 클라이언트 JAR의 MANIFEST 파일을 덮어씁니다.
현재는 해결 방법이 없습니다.
CGI-bin 및 SHTML과 같은 동적 내용 기술은 더 이상 지원되지 않습니다.
JSP 및 웹 서비스 기술을 대신 사용하십시오.
이 절에서는 데이터베이스 드라이버와 관련된 알려진 문제점과 해결 방법을 설명합니다.
다른 응용 프로그램 서버에서 응용 프로그램을 이식하면 연결이 시간 초과된 후 물리적 연결이 제대로 닫히지 않습니다. 이 문제는 동일한 DB2 7.1.x 데이터베이스 서버에 대한 DB2 8.1.x 버전의 클라이언트 라이브러리(Type II) 드라이버에서 발생합니다.
SteadyPoolSize와 MaxPoolSize를 동일한 숫자로 설정하고 Idle Connection 시간 초과를 0으로 설정합니다. 그러면 유휴 연결에 대한 시간 초과가 비활성화되고 전체 연결을 사용할 수 있습니다.
이 절에서는 Deploytool과 관련된 알려진 문제점과 해결 방법을 설명합니다.
sun-application-client.xml
sun-ejb-jar.xml
sun-web.xml
메시지 대상 탭에서 JNDI 이름으로 지정된 JMS 대상 자원은 Sun 설명자에 저장될 수 없습니다. 대상 이름(예: create-jmsdest를 사용하여 생성된 물리적 대상인 PhysicalQueue)을 지정한 후 Enter 키를 누르면 대상 이름이 디스플레이 이름 아래에 나타나고 클라이언트 또는 Bean 이름이 생성자 목록에 나타납니다. Sun 특정 JNDI 이름 텍스트 필드에 "jms/Queue"를 입력한 후 Enter 키를 누르면 응용 프로그램이 제목 표시줄에 "(changed)"로 표시되지 않고 ~/.deploytool/logfile에 오류가 기록됩니다. 응용 프로그램을 저장하고 탭으로 다시 돌아가면 JNDI 이름 필드가 다시 비워집니다. 도구\>설명자 뷰어\>Application Server 설명자를 사용하여 Sun 설명자를 볼 경우 <jndi-name\> 요소 내의 <message-destination\> 요소가 만들어지지 않습니다.
Deploytool 세션 중에 메시지 대상 JNDI 이름 값을 처음으로 입력하면 값이 Sun 설명자에 올바르게 표시되지만 org.netbeans.modules.schema2beans.BeanProp.setElement()에서 IllegalArgumentException이 발생합니다. 동일한 응용 프로그램이나 다른 응용 프로그램에서 이후에 메시지 대상 JNDI 이름을 변경하거나 추가하면 해당 내용이 Sun 설명자에 저장되지 않습니다.
메시지 대상의 기존 JNDI 이름을 편집하려면 다음을 수행합니다.
JNDI 이름 텍스트 필드를 비워두고 Enter 키를 눌러 기존 JNDI 이름을 삭제합니다.
새 JNDI 이름을 입력하고 Enter 키를 누릅니다.
도구\>설명자 뷰어\>Application Server 설명자를 눌러 Sun 설명자를 검토합니다.
파일\>저장을 눌러 응용 프로그램을 저장합니다.
JNDI 이름이 Sun 설명자에 저장되지 않는 경우 다음을 수행합니다.
Deploytool을 다시 시작합니다.
메시지 대상 탭에서 메시지 대상을 선택하거나 새 메시지 대상을 추가합니다.
Sun 특정 JNDI 이름 텍스트 필드에 메시지 대상의 JNDI 이름을 입력한 다음 Enter 키를 누릅니다.
도구\>설명자 뷰어\>Application Server 설명자를 눌러 Sun 설명자를 검토합니다.
파일\>저장을 눌러 응용 프로그램을 저장합니다.
Deploytool 세션 중에 JNDI 이름 텍스트 필드에 처음으로 값을 입력하는 경우를 제외하고 메시지 대상 탭에서 Sun 특정 JNDI 이름 값을 입력할 때마다 위의 단계를 반복합니다.
Deploytool에서 Enterprise Bean을 만든 다음 bean 노드의 트랜잭션 또는 보안 탭으로 이동하면 "Local Home" 및 "Remote Home" 레이블이 "Local Installation Directory" 및 "Remote Installation Directory"로 잘못 번역되어 있습니다.
이 절에서는 설명서와 관련된 알려진 문제점과 해결 방법을 설명합니다.
AMX(Application Server Management eXtenstions) 설명서에서는 Application Server Platform Edition 8.2에서 사용할 수 없는 일부 모니터링 기능을 지정하지 않습니다. Platform Edition에서 모니터링할 수 없는 구성 요소는 다음과 같습니다.
PWC(Production Web Container):
PWC HTTP 서비스
PWC 연결 대기열
PWC 스레드 풀
PWC DNS
PWC 연결 유지
PWC 파일 캐시
PWC 가상 서버
PWC 요청
Webmodule
SessionSize
ContainerLatency
SessionPersistTime
CachedSessionsCurrent
PassivatedSessionsCurrent
StatefulSessionStore
CheckpointCount
CheckpointSuccessCount
CheckpointErrorCount
CheckpointedBeanSize
CheckpointTime
해결 방법이 필요하지 않습니다. 이 통계는 Platform Edition과 관련이 없습니다.
Sun Java System Application Server Platform Edition 8.2 Developer’s Guide의 2장, Securing Applications에 나오는 Realm Configuration 절이 com.sun.appserv.AbstractLoginModule 확장으로 잘못 참조되어 있지만, 이 클래스의 이름은 com.sun.appserv.AppservLoginModule입니다.
com.sun.appserv.AbstractLoginModule 대신 com.sun.appserv.AppservLoginModule을 참조합니다.
--passwordfile에 대한 짧은 옵션은 없습니다. 현재 -W --passwordfile은 설명서 페이지에 설명되어 있습니다. 이 내용은 잘못되었습니다.
Application Server 8.2 Platform Edition에서는 —W 옵션을 --passwordfile과 함께 사용하지 마십시오. 짧은 옵션은 이후 Application Server 릴리스에 추가될 예정입니다.
NumConnAcquired 및 NumConnReleased 통계를 위한 getter 메소드가 ConnectorConnectionPoolStats 및 AltJDBCConnectionPoolStats에 없습니다. 이러한 getter 메소드는 이후 릴리스에서 getNumConnAcquired() 및 getNumConnReleased()로 추가됩니다.
EJBCacheStats에서 getPassivationSuccesses(), getExpiredSessionsRemoved(), getPassivationErrors(), getPassivations() 메소드를 호출하면 예외가 발생합니다. 이 문제는 이후 릴리스에서 수정될 예정입니다.
서버를 시작한 후 몇 초가 지나야 AMX Mbean을 등록하고 사용할 수 있습니다. 이후 릴리스에서는 AMX MBean이 언제 가득 차는지 확인할 수 있습니다.
XTypes.CONNNECTOR_CONNECTION_POOL_MONITOR 상수가 잘못 표기되어 있습니다("NNN"). 이 문제는 이후 릴리스에서 수정될 예정입니다.
이 절에서는 설치/설치 제거와 관련된 알려진 문제점과 해결 방법을 설명합니다.
이 문제는 Solaris x86 플랫폼에서 간헐적으로 보고되었지만 Solaris SPARC 및 Linux 플랫폼에서도 발생할 수 있습니다.
문제는 설치 프로그램 또는 설치 제거 프로그램의 처음 화면에 전체 텍스트와 "도움말" 및 "취소" 버튼은 제대로 표시되지만 다음 화면으로 이동하는 "다음" 버튼이 보이지 않는 것입니다. 버튼은 보이지는 않지만 활성화되어 있으며 버튼이 있어야 할 부분을 누르면 정상적으로 다음 화면으로 이동합니다. 이 문제는 간헐적인 J2SE GUI 다시 그리기 문제 때문입니다.
한 가지 해결 방법은 도움말 버튼 왼쪽의 다음 버튼 영역을 누르는 것입니다. 또 다른 해결 방법은 화면 크기를 약간 바꾸거나 설치 프로그램 창을 최소화했다가 복원하여 화면을 다시 그리는 방법입니다. 다시 그린 후에는 다음 버튼이 보이게 됩니다.
이 문제는 몇몇 Linux 시스템에서 발견되었습니다. Java Desktop System 2에서 가장 일반적으로 나타나는 문제이지만 RedHat 배포에서도 발견되었습니다.
설치 프로그램의 마지막 화면에서 마침 버튼을 누른 후 설치 프로그램에서 제품 정보 페이지나 제품 등록 페이지가 있는 브라우저 창을 시작하는 데 실패하고 명령 프롬프트를 반환하지 않은 채 무기한 중단됩니다.
설치 프로그램을 시작했던 단말기 창에서 Ctrl+C를 눌러 설치 프로그램을 종료합니다. 이렇게 하면 제품 정보 페이지나 등록 페이지가 있는 브라우저 창이 시작됩니다. 그러나 브라우저 창이 나타나지 않는 경우에는 브라우저를 시작하고 다음 URL을 입력하면 정보 페이지를 볼 수 있습니다.
file://install_dir/docs/about.html
제품을 등록하기 위해 설치 옵션을 선택한 경우에는 제품 정보 페이지에 있는 등록 페이지 링크를 따라 가십시오.
Linux 설치 프로그램을 시작하는 setup 실행 프로그램이 중단되는 경우가 있습니다. J2SE 위치를 해결하고 설치 마법사를 시작하는 대신 래퍼가 중단되고 다음 메시지가 표시됩니다.
Chcking available disk space.... Checking Java(TM) 2 Runtime Environment.... Extracting Java(TM) 2 Runtime Environment.... Deleting temporary files.....
이 문제는 일부 Linux 버전에서만 나타나며 환경 설정, 특히 JAVA_HOME 변수의 영향을 받는 것으로 보입니다.
이 문제를 해결하려면 다음을 수행합니다.
쉘에 따라 unset 또는 unsetenv를 실행하여 JAVA_HOME 변수 설정을 해제합니다.
setup 명령을 -javahome 옵션과 함께 실행하여 설치 프로그램에서 사용되는 JAVA_HOME을 지정합니다.
이 절에서는 라이프사이클 관리와 관련된 알려진 문제점과 해결 방법을 설명합니다.
[echo] Doing admin task set [exec] [Attribute(id=redelivery-interval-internal-in-millis) : Redelivery- Interval (7,000) should be greater than or equal to Minimum-delivery- interval-in-millis (9,000)] [exec] CLI137 Command set failed.
minimum-delivery-interval은 같은 기간 타이머 전달 간의 최소 간격 기간입니다.
redelivery-interval-in-mills는 타이머 서비스가 실패한 ejbTimeout 이후 재전달을 시도하기까지 기다리는 시간입니다.
문제는 재전달 간격 등록 정보를 최소 전달 등록 정보와 관련시키는 논리가 잘못되어 최소 전달 간격이 재전달 간격보다 큰 곳에서 GUI 또는 CLI를 사용하여 값을 설정하지 못한다는 것입니다.
minimum-delivery-interval-in-millis는 항상 ejb-timer-service 등록 정보 redelivery-interval-in-millis와 같거나 그보다 크게 설정해야 합니다. 문제는 Application Server에서 redelivery-interval-in-millis 값이 minimum-delivery-interval-in-millis 값보다 크다고 확인하는 잘못된 검증 확인이 있는 것입니다.
다음과 같이 등록 정보의 기본값을 사용합니다.
minimum-delivery-interval(default)=7000 redelivery-interval-in-millis(default)=5000
기본값 외의 값을 사용하면 오류가 발생합니다.
이 절에서는 로깅과 관련된 알려진 문제점과 해결 방법을 설명합니다.
JVM에 대해 java.security.debug 옵션을 설정하면 서버 인스턴스 시작이 교착 상태로 중단됩니다. 예를 들어 domain.xml에 다음과 같이 설정하면 이러한 문제가 발생합니다.
<jvm-options\>-Djava.security.debug=access,failure</jvm-options\>
현재는 해결 방법이 없습니다. 이 플래그를 설정하는 것을 피하십시오.
이 절에서는 Application Server 8.2 제품에 포함된 샘플 코드와 관련된 알려진 문제점과 해결 방법을 설명합니다.
<install_dir>/samples/webservices/jaxrpc/apps/managementws에서 검증자를 실행하는 경우 다음과 같은 경고가 발생합니다.
[exec] WARNING: /var/tmp/exploded20051214111425/managementws/ \ managementwsEjb_jar contains library/castor-0.9.3.9-xml.jar in Class-Path manifest attribute, but it is not found in ear file [exec] Dec 14, 2005 11:14:30 AM Archive getBundledArchives [exec] WARNING: /var/tmp/exploded20051214111425/managementws/ \ managementwsEjb_jar contains library/castor-0.9.3.9-xml.jar in Class-Path manifest attribute, but it is not found in ear file |
Application Server 8.2 릴리스에서 Castor jar이 업데이트되었으므로 이전 castor-0.9.3.9-xml.jar에 대한 모든 참조를 최신 castor-0.9.9.1.jar로 변경해야 합니다. 특히, MANIFEST.MF 파일에서 참조를 변경하여 이전 castor-0.9.3.9-xml.jar 대신 castor-0.9.9.1.jar을 사용해야 합니다.
다음과 같은 이전 Castor jar에 대한 참조를 최신 Castor jar로 변경합니다.
이전:
src/conf/MANIFEST.MF:Class-Path: library/castor-0.9.3.9-xml.jar src/conf/MANIFEST.MF:Name: library/castor-0.9.3.9-xml.jar managementws-ejb/src/conf/MANIFEST.MF:Class-Path: \ library/castor-0.9.3.9-xml.jar |
최신:
src/conf/MANIFEST.MF:Class-Path: library/castor-0.9.9.1.jar src/conf/MANIFEST.MF:Name: library/castor-0.9.9.1.jar managementws-ejb/src/conf/MANIFEST.MF:Class-Path: \ library/castor-0.9.9.1.jar |
그런 다음 배포 중에 Castor .jar을 install_dir/lib에 복사하지 않고 배포 해제 중에 이 파일을 제거하도록 build.xml 파일을 정리합니다. build.xml 파일의 이전 버전과 최신 버전의 차이점은 다음과 같습니다.
% cvs diff build.xml Index: build.xml =================================================================== RCS file: /m/jws/samples/samples8x/webservices/jaxrpc/apps/managementws/ \ managementws-standalone-client/ Attic/build.xml,v retrieving revision \ 1.1.2.3 diff -r1.1.2.3 build.xml 80,89d79 < <target name="remove_castor_from_classpath"> < <delete file="${com.sun.aas.installRoot}/lib/castor-0.9.9.1.jar"/> < </target> < <target name="add_castor_to_classpath"> < <delete file="${com.sun.aas.installRoot}/lib/castor-0.9.9.1.jar"/> < <copy file="../lib/castor-0.9.9.1.jar" \ todir="${com.sun.aas.installRoot}/lib" /> < </target> < < <target name="setup" depends="add_castor_to_classpath, restart.server"/> < jbenoit/galapago 196 >pwd /net/galapago.east/files/share/8.2ws/samples/samples8x/webservices/jaxrpc \ /apps/managementws/managementws-standalone-client jbenoit/galapago 197 >cd .. jbenoit/galapago 198 >cvs diff build.xml Index: build.xml =================================================================== RCS file: /m/jws/samples/samples8x/webservices/jaxrpc/apps/managementws/ \ Attic/build.xml v retrieving revision 1.1.2.4 diff -r1.1.2.4 build.xml 28,36d27 < <target name="setup"> < <ant antfile="build.xml" inheritAll="true" dir="${sample.name}$ \ {standalone-client-dir-suffix}" target="setup"/> < </target> < < <target name="unsetup"> < <ant antfile="build.xml" inheritAll="true" dir="${sample.name}$ \ {standalone-client-dir-suffix}" target="remove_castor_from_classpath"/> < </target> < < 53,54c44,45 < <target name="deploy" depends="select_binary_common, deploy_common, setup" /> < <target name="undeploy" depends="init, undeploy_common, unsetup"/> --- > <target name="deploy" depends="select_binary_common, deploy_common" /> > <target name="undeploy" depends="init, undeploy_common"/>
이 절에서는 보안과 관련된 알려진 문제점과 해결 방법을 설명합니다.
응용 프로그램 클라이언트가 사용자 이름과 비밀번호를 다른 웹 서비스 클라이언트로 전달하지 않습니다.
필요한 경우 사용자 이름/비밀번호 조합을 클라이언트 프로그램에 다음과 같이 명시적으로 전달합니다.
((Stub)yourWSPort)._setProperty(Stub.USERNAME_PROPERTY, "yourUsername"); ((Stub)yourWSPort)._setProperty(Stub.PASSWORD_PROPERTY, "yourPassword");
이 절에서는 업그레이드 유틸리티와 관련된 알려진 문제점과 해결 방법을 설명합니다.
업그레이드 유틸리티를 실행하고 install_dir을 소스 설치 디렉토리로 식별하는 동안 install_dir/domains 디렉토리에 생성된 도메인만 업그레이드됩니다. 다른 위치에 생성된 도메인은 업그레이드되지 않습니다.
업그레이드 프로세스를 시작하기 전에 다른 위치에 있는 모든 도메인 디렉토리를 install_dir/domains 디렉토리로 복사합니다.
여러 도메인을 가진 8.0 Application Server를 업그레이드하면 JMX 커넥터에 대해 동일한 포트 번호가 구성되기 때문에 이들 도메인이 동시에 시작되지 못할 수 있습니다.
포트 값을 변경합니다.
install dir /domains/domain1/config/domain.xml 파일에서 다음 항목을 확인합니다.
<jmx-connector accept-all="false" address="0.0.0.0" auth-realm-name= "admin-realm" enabled="true" name="system" port="8686" protocol="rmi_jrmp" security-enabled="false"/\>" -- and in file <as 8.1 install dir\> /domains/domain1/samples/config/domain.xml, notice it used the same port "8686", so it failed to start domain due to port conflict. |
포트 값 8686을 8687로 변경한 다음 domain1을 다시 시작합니다.
이 문제는 몇몇 Linux 시스템에서 발견되었으며 Java Desktop System 2에서 가장 일반적으로 나타나지만 RedHat 배포에서도 볼 수 있습니다.
마지막 설치 프로그램 화면의 업그레이드 도구 시작 버튼을 누른 후 설치 프로그램에서 업그레이드 도구를 시작하여 업그레이드 프로세스를 완료하는 데 실패하고 명령 프롬프트가 반환되지 않은 채 무기한 중단됩니다.
이 문제는 명령줄 설치 모드를 사용하여 현재 위치에서 업그레이드를 실행하는 경우에는 발생하지 않습니다.
현재 위치에서 업그레이드를 GUI 모드에서 실행하고 이 문제가 발생하면 설치 프로그램이 시작된 단말기 창에서 Ctrl+C를 눌러 설치 프로그램을 종료합니다.
단말기 창에서 다음 명령을 사용하여 업그레이드 도구를 시작합니다.
install_dir/bin/asupgrade --source install_dir/domains --target install_dir --adminuser adminuser--adminpassword adminpassword --masterpassword changeit |
adminuser 및 adminpassword는 업그레이드 중인 설치를 위해 사용되는 값이 일치해야 합니다.
업그레이드 도구에서 업그레이드 프로세스를 완료하면 브라우저를 시작하고 다음 URL을 입력하여 정보 페이지를 검토할 수 있습니다.
file://install_dir/docs/about.html
제품을 등록하기 위해 설치 옵션을 선택한 경우에는 제품 정보 페이지에 있는 등록 페이지 링크를 따라 가십시오.
일부 로켈을 사용하여 다국어 버전의 Application Server 8.2에서 이후 버전으로 업그레이드할 때 결과 패널 외에 /opt/SUNWappserver/domains/upgrade.log 파일에도 가비지 문자가 표시될 수 있습니다.
현재는 해결 방법이 없습니다. 이 문제는 이후 Application Server 릴리스에서 수정될 예정입니다.
이 절에서는 웹 컨테이너와 관련된 알려진 문제점과 해결 방법을 설명합니다.
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\qt be deleted
응용 프로그램을 배포할 때 --precompilejsps=false(기본 설정)를 지정하면 이 문제가 발생하지 않습니다. 응용 프로그램을 처음 사용하면 JSP 컴파일이 트리거되어 첫 번째 요청에 대한 응답 시간은 이후의 요청에 대한 응답 시간보다 더 깁니다.
사전 컴파일을 수행하면 응용 프로그램을 배포 해제 또는 재배포하기 전에 서버를 중단하고 다시 시작해야 합니다. 서버를 종료하면 잠긴 JAR 파일의 잠금이 해제되어 재시작한 후 배포 해제 또는 재배포를 성공적으로 수행할 수 있습니다.
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 페이지에 액세스하지만 컴파일에 실패하며, 서버 로그에 다음과 같은 스택 추적과 함께 "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로 설정합니다.
이 작업은 다음 중 한 가지 방법으로 수행할 수 있습니다.
${S1AS_HOME}/domains/domain1/config/default-web.xml에서 JspServlet의 fork init 매개 변수를 false로 전역 설정합니다.
<servlet\> <servlet-name\>jsp</servlet-name\> <servlet-class\>org.apache. jasper.servlet.JspServlet</servlet-class\> .... <init-param\> <param-name\> fork</param-name\> <param-value\>false</param-value\> </init-param\> .... </servlet\>
웹 응용 프로그램별로 sun-web.xml의 fork JSP 구성 등록 정보를 false로 설정합니다.
<sun-web-app\> <jsp-config\> <property name="fork" value="false" /\> </jsp-config\> </sun-web-app\>
어떤 방법으로 설정하든 ant에서 javac 컴파일을 위한 새로운 프로세스를 생성하지 못하도록 합니다.
Application Server PE의 기본 구성은 다중 CPU 시스템에서 최적의 상태로 실행되지 않습니다. 시작이 더 빨라진다는 장점이 있지만 이는 웹 응용 프로그램의 성능에 부정적인 영향을 줄 수 있습니다.
다음 JVM 옵션을 사용하도록 Application Server를 구성합니다.
-Dcom.sun.enterprise.server.ss.ASQuickStartup=false
비호환 빠른 정보 집합 인코딩 SOAP 메시지가 JAX-RPC 서비스로 전송되면 서비스가 제대로 응답하지 않습니다. 그러나, 동일한 서비스 또는 동일한 JAX-RPC 런타임을 사용하여 배포된 서비스에 전송되는 이후의 호환 빠른 정보 집합 인코딩 SOAP 메시지에서 잘못된 오류가 발생할 수 있습니다.
다음과 같은 방법으로 해결할 수 있습니다.
XML 인코딩 SOAP 메시지만 전송되도록 클라이언트에서 빠른 정보 집합 지원을 비활성화합니다.
호환 빠른 정보 집합 인코딩 SOAP 메시지가 전송될 수 있도록 서비스를 배포하는 컨테이너를 다시 시작합니다.