공유 라이브러리는 클래스 라이브러리를 여러 Application에서 공유해서 사용하도록 하는 기능이다. 기존의 JEUS_HOME\lib\application 디렉터리와 차이점은 JEUS 전체에 영향을 미치지 않고, Application에서 설정해서 사용할 수 있다는 점이다.

만약 JSF 1.1을 사용하는 Application과 JSF 1.2를 사용하는 Application이 있을 경우, JSF 1.1과 1.2를 공유 라이브러리로 추가하고 Application에서 선택해서 사용하면 서로간의 충돌 없이 동작하게 된다.

자세한 내용은 “JEUS Applications & Deployment 안내서”의 “1.2. 공유 라이브러리(Shared Library)” 과 “JEUS Web Container 안내서”의 “6.3.3. Shared Library에 대한 레퍼런스 추가”의 "JSF1.2, JSTL1.2 라이브러리 설정"을 참조한다.

기존에는 deploy_home을 통해서만 Auto deploy가 가능했었다. 그러나 JEUSMain.xml의 <application> 태그로 모듈별 Auto deploy가 가능하도록 하는 기능이 추가되었다.

..
<application>
   <absolute-path>d:\jeus6\webhome\app_home</absolute-path>
   <name>hello</name>
   <path>hello.jar</path>
   <deployment-type>COMPONENT</deployment-type>
   <deployment-target>
      <target>
         <node-name>jeus6</node-name>
      </target>
   </deployment-target>
   <classloading>ISOLATED</classloading>
   <class-ftp-unit>JAR</class-ftp-unit>
   <auto-deploy>
      <check-absolute-path>true</check-absolute-path>
      <auto-deploy-check-interval>10000</auto-deploy-check-interval>
   </auto-deploy>
</application>
...

자세한 내용은 “JEUS Applications & Deployment 안내서”의 “3.5. Auto Deploy”을 참조한다.

일반적으로 JEUS가 부팅될 때, 모든 Engine Container도 부팅하게 된다. 여기에 Engine Container가 부팅될지 여부를 설정할 수 있다. 부팅이 되지 않도록 했더라도 부팅 후에 WebAdmin을 통해서 컨테이너를 부팅시킬 수 있다.

JEUS Manager나 Engine Container에 여러 개의 로거를 등록할 수 있게 되었다. 이로써, 필요한 로그를 별도로 분리해서 로깅할 수 있게 되었다. 다음의 예제는, JEUS의 기본 로깅은 SEVERE 레벨로, jeus.servlet.connection과 jeus.transaction 로거는 FINE 레벨로 로깅하는 설정이다.

..
<system-logging>
   <name>jeus</name>
   <level>SEVERE</level>
   </handler>
</system-logging>
<system-logging>
   <name>jeus.servlet.connection</name>
   <level>FINE</level>
</system-logging>
<system-logging>
   <name>jeus.transaction</name>
   <level>FINE</level>
</system-logging>
...

자세한 내용은 “JEUS Server 안내서”의 “제11장 Logging”을 참조한다.

기존에 용도 별로 따로 제공되던 콘솔 툴이 jeusadmin 하나로 통합되었다.

jeusadmin과 jmsadmin에 대한 내용은 각각 “JEUS Reference Book”의 “4.2. jeusadmin”과 “JEUS Reference Book”의 “4.3. jmsadmin”을 참고한다.

EJB 3.0을 사용할 경우 Stub/Skeleton을 생성하지 않고 빠르게 deploy할 수 있다.

기존 JDK의 RMI가 아닌 JEUS 고유의 프로토콜을 사용하는 RMI를 사용할 수 있다. 최신 NIO 기술을 사용함으로써, 대용량의 EJB Client 호출을 효율적으로 처리할 수 있다.

Stateful Session Bean에서 기본적으로 Session Manager를 사용하도록 하여, EJB passivation이나 EJB Clustering에서 보다 완벽한 Fail over가 가능하다.

Fail over에 대한 자세한 설명은 “JEUS EJB 안내서”의 “제6장 EJB 클러스터링”과 “JEUS EJB 안내서”의 “제7장 Session Bean”을 참조한다.

모든 EJB의 passivate-timeout과 disconnect-timeout을 일괄적으로 적용하는 시스템 프로퍼티가 추가되었다.

추가된 프로퍼티는 다음과 같다.

각 프로퍼티에 대한 자세한 설명은 “JEUS Reference Book”의 “1.9. EJB 시스템 프로퍼티”를 참조한다.

기존 Blocking HTTP Listener 에서는 요청 처리 스레드가 커넥션과 일대일로 대응되는 관계여서 동시에 처리할 수 있는 커넥션 개수가 worker thread 수만큼 제한되는 문제가 있었다. JEUS 6 에서는 JDK NIO (Non-blocking I/O)에 기반한 HTTP Listener를 제공하고 있다. 따라서 많은 커넥션을 적은 수의 스레드로 안정적으로 처리할 수 있어서 시스템 리소스 사용을 줄일수 있다. HTTP Listener 뿐 아니라 TCP Listener또한 NIO 기반의 Listener를 지원한다.

NIO Listener 의 사용은 기존의 Listener 설정에 <use-nio>true</use-nio> 태그를 추가하는 것만으로 간단히 가능하다. 자세한 설명은 “JEUS Web Container 안내서”의 “4.3.1. HTTP, TCP, HTTPS 리스너 설정”을 참조한다.

Servlet Filter를 사용하여 HTTP 응답 전체를 Caching하는 기능이 추가되었다. 빈번하게 요청되는 정적 컨텐츠에 대해서 사용하면 Caching되어 있는 데이터를 사용하게 되므로 웹 애플리케이션의 전체적인 응답시간을 향상시킬수가 있다.

태그 라이브러리(tag library)를 이용하여 JSP 내의 일부분을 Caching하는 기능이 추가되었다. 전체 페이지 중에서 부분 변경이 발생하는 JSP 페이지를 요청할 때 적합하다. 최초 작성 이후 변경되지 않거나, 변경 빈도수가 적은 부분을 JEUS WebCache에 저장하여 JSP 요청할 때 Caching되어 있는 데이터를 이용함으로써 웹 애플리케이션의 성능을 향상할 수 있다.

자세한 설명은 “JEUS Web Container 안내서”의 “제8장 JEUS WebCache”를 참조한다.

외부의 요청을 내부 서버에 전달하고 해당 응답을 다시 외부로 전달해주는 Reverse Proxy 기능이 추가되었다. 자세한 설명은 “JEUS Web Container 안내서”의 “제9장 Reverse Proxy”를 참조한다.

jeus-web-dd.xml을 사용하여 애플리케이션(웹 모듈)별로 request, response encoding을 설정하는 기능이 추가되었다. WEBMain.xml의 ContextGroup에서도 기존과 같이 설정할 수 있으며, 둘 다 설정된 경우 jeus-web-dd.xml 설정이 우선한다. encoding 설정이 WEBMain.xml의 ContextGroup에서만 가능하여 일괄 적용될 수밖에 없었던 불편함이 이 기능이 추가됨으로써 해소되었다.

별도의 Deployment Description을 작성할 필요없이, 기존의 클래스에 간단히 Metadata Annotation을 추가하는 것으로 Web Service를 개발할 수 있게 되었다. 또한 바이너리 파일 전송 등에서 효율적인 기능을 제공하며, 비동기 Web Service 기능을 제공한다.

JAXB 2.1 프레임워크을 이용하여 SOAP과 Java 간의 타입 매핑을 제공함으로써, 다양한 형태의 스키마 타입으로 정의되는 SOAP 메시지를 빠른 속도로 처리 가능하게 되었다.

SOAP/HTTP 뿐만 아니라 XML/HTTP 기능을 제공하여, Web Service 제공자와 소비자 간에 주고받는 메시지를 유연하게 처리할 수 있게 되었다. 이를 바탕으로 RESTful Web Service도 지원한다.

WS-ReliableMessaing, WS-Security, WS-Policy, WS-Addressing 등 부가적인 WS 확장 Stack을 지원하여, 다양한 환경에서 최적을 솔루션을 제공하고 있다.

Session을 생성할 때 acknowledge모드를 jeus.jms.JeusSession.NONE_ACKNOWLEDGE로 설정할 수 있다.

이 모드는 producer는 send할 때 서버로부터 ack을 수신하지 않고, consumer는 receive할 때 서버로 ack을 전송하지 않기 때문에 빠른 속도로 메시지를 주고받을 수 있다.

자세한 내용은 “JEUS MQ 안내서”의 “2.3.6. NONE_ACKNOWLEDGE 모드”를 참조한다.

JMS를 통해서 대용량의 파일을 보낼 수 있는 기능이 추가되었다. JMS는 메시지를 메모리에 올려서 송수신 하기 때문에, 메시지 크기가 클 경우 OutOfMemoryError가 발생할 수도 있지만, FileMessage는 파일의 내용을 블록 단위로 전송하기 때문에 이와 같은 문제를 피할 수 있다.

FileMessage의 구조는 다음과 같다.

public interface FileMessage extends javax.jms.Message 
{
    public java.net.URL getURL();
    public void setURL(javax.net.URL url) throws MessageNotWriteableException;
    public boolean isURLOnly();
    public void setURLOnly(boolean urlOnly);
}

Active-Standby기능은 2개의 JMS가 clustering되어 있을 때, Active로 설정된 JMS만 서비스하게 하고, Active JMS가 down되었을 때에만 Standby JMS로 서비스하도록 하는 Fail-Over 기능이다.

이 기능을 제어하기 위해서 jmsadmin 콘솔 툴에 takeover, recover, cluster 명령이 추가되었다.

중앙 세션 서버의 경우 모든 컨테이너들의 세션이 중앙으로 집중되어 전체 세션 크기가 클 경우 메모리를 감당하지 못하고 OutOfMemoryError가 발생할 수 있다. 이럴 경우 logical한 세션 메모리에 한계치를 적용하여 그 이상이 될 경우 passivation을 시키는 기능이 추가되었다. 다음은 관련 시스템 프로퍼티이다.

자세한 내용은 JEUS Reference Book 및 “JEUS Server 안내서”의 절 10.2.1. “Session Manager의 메모리 관리”를 참조한다.

분산 세션 서버에서 백업을 설정할 때 어떤 컨테이너의 어떤 엔진을 설정해야 할지 고민할 필요 없이 JEUS에서 가장 적절한 백업 서버를 자동으로 선택하여 클러스터링 한다. 물론 특정 백업 서버를 원할 경우 강제적으로 지정해 주는 기능은 제공된다. 자세한 내용은 “JEUS Server 안내서”의 절 10.3.1. “분산 세션 서버의 백업 서버 선택 방식”을 참조한다.

사용자가 DataSource의 Statement를 이용해서 Query를 실행했을 때, Query가 지정된 시간 동안 끝나지 않으면 SQLException을 던지는 기능이 추가되었다. 자세한 내용은 “JEUS Server 안내서”의 “8.3. JDBC 데이터소스 설정”을 참조한다.

지정한 시간이 지나면 주기적으로 Check Query를 실행시키는 기능이 추가되었다. JEUS와 DBMS 간에 방화벽이 있을 경우, DB connection 유지 등을 위해서 사용할 수 있다. 자세한 내용은 “JEUS Server 안내서”의 “8.3. JDBC 데이터소스 설정”을 참조한다.

Java의 표준 기능인 Java Authentication&Authorization Service 기능을 이용해서 JEUS의 권한 인증과 부여 기능을 작성할 수 있다. 기존 JEUS에서 Custom 서비스를 제공하고 있으나, 다양한 JAAS 모듈 적용이 가능하게 됨으로써 보다 광범위한 서비스 개발이 가능하게 되었다. 자세한 내용은 “JEUS Security 안내서”의 “제7장 JAAS 사용”을 참조한다.

LDAP과 DB Realm을 이용한 User Authentication과 Authrization 기능이 제공된다. 특히 DB Realm의 경우에는 성능 향상을 위한 Caching을 제공하므로, 빠른 성능을 제공한다. 자세한 내용은 “JEUS Security 안내서”의 “제7장 JAAS 사용”을 참조한다.

JEUS의 AP에서 System.exit()와 같은 잘못된 수행에 대한 권한 체크를 기본으로 제공하는 Default Security Manager 옵션을 제공한다. 또한 JEUS에서 사용하는 포트의 동작을 로깅할 때도 사용된다.

Engine Container에 -Djeus.security.enable.default.manager=true를 넣는 것으로 간단히 지원된다. 자세한 내용은 “JEUS Reference Book”의 “1.10. 보안 시스템 프로퍼티”를 참조한다.

JEUS의 MBean 내용을 모니터링하는 화면이 추가되었다.

현재 진행 중인 트랜잭션의 ID와 트랜잭션 정보를 모니터링할 수 있다.

JEUS에서 사용하는 스레드의 개수와 풀 정보, 현재 동작 중인 스레드의 개수 등을 모니터링하는 기능이 추가되었다.

WebAdmin의 화면에 따라서 적합한 도움말이 제공되도록 하였다.

JEUS의 가상 노드를 설정하는 파일이 vhost.properties로 변경되었다.

설정 형태는 다음과 같다.

다음은 실제 사용한 예제이다.

jeus.vhost.enabled=true
jeus6=johan:9736

이전 버전까지 deploy_home이었던, Auto deploy 디렉터리 이름이 autodeploy로 변경되어 보다 명확한 의미 전달이 되도록 하였다.

기존에 제공하던 2가지의 Class Loader 중 ISOLATED 방식이 기본 Class Loader로 변경되었다.

ISOLATED 방식은 애플리케이션별로 각각의 Class Loader가 독립적으로 생성되어 동작하는 방식이다. 그러므로 Servlet에서 EJB를 호출하기 위해서는 다음 2가지 중 하나를 사용해야 한다.

ISOLATED 방식의 Class Loader에 대해서는“JEUS Server 안내서”의 “1.5.1. Isolated Class Loader”를 참고한다.

기존에 제공하던 HSQL DB 대신에 Apache Derby을 제공한다. Apache Derby에 대한 자세한 내용은 Apache Derby 사이트를 참고한다.

JEUS WebServer를 띄위기 위해서 사용하던 WS engine 디렉터리와 그 설정 파일인 WSMain.xml이 제거되었다. JEUS WebServer를 JEUS를 부팅할 때 기동시키려면 단지 JEUSMain.xml에서 ws engine만 등록해 주면 되도록 변경되었다.

Microsoft의 COM과 EJB 연동을 지원하는 COM Bridge와 타 언어 기반에서 EJB를 호출할 수 있도록 지원하는 CAS는 더 이상 지원하지 않는다. 타 플랫폼과의 연동은 표준 Web Serivce를 통하는 방법이 훨씬 안정적이기 때문이다.

EJB 3.0 Specification에 따라서 EJB 3.0에서 특별히 Transaction Attribute를 지정하지 않았을 때는 기본적으로 Required가 적용된다. 그러나 EJB 2.x에서는 호환성을 위해서 그대로 Supports가 적용된다.

기본 Transaction Atrribute를 변경하려면 다음 시스템 파라미터를 JEUSMain.xml의 <command-option>에 적용해서 변경할 수 있다.

-Djeus.ejb.transaction.attribute.default=<Transaction Attribute>

오픈소스 웹 프레임워크를 보다 잘 지원하고 호환성 문제를 줄이기 위해서 톰캣 Jasper 기반의 JSP Parser를 디폴트로 변경하였다. 이 Parser는 JSP 스펙과 동일한 수준에서 엄격하게 문법 체크를 하기 때문에 기존 JSP Parser에서 지원한 비표준적인 문법을 사용한 경우 에러가 발생할 수 있다. 기존 웹 모듈을 업그레이드하지 않는 경우에는 jeus-web-dd.xml에 jeus.servlet.jsp.modern 옵션을 false로 설정해서 JEUS5에 디폴트로 제공된 Parser를 사용할 수 있다. 자세한 내용은 “JEUS Web Container 안내서”의 “6.3.4. 하위 호환성을 위한 Context 레벨의 추가 옵션 설정”을 참조한다.

기존에 jspc2로 제공되던 JSP 배치 컴파일러 콘솔 툴은 appcompiler에 통합되었다.

appcompiler의 자세한 사용법은 “JEUS Reference Book”의 “4.4. appcompiler”를 참고한다.

jspc 배치 컴파일러는 그대로 제공되지만 deploy할 때 JSP 프리 컴파일을 지원하기 때문에 일반적인 경우에는 사용할 필요가 없다. 이에 대해서는 “JEUS Web Container 안내서”의 “6.3.10. 배치 컴파일러를 사용한 JSP 프리컴파일”을 참조한다.

ContextGroup뿐 아니라 각각의 애플리케이션 단위로도 encoding 설정이 가능하도록 기능이 향상되었다.

WEBMain.xml 의 ContextGroup과 jeus-web-dd.xml에 동시에 설정될 경우 jeus-web-dd.xml 설정이 우선한다. 또한 애플리케이션에서 설정한 encoding 값이 최우선으로 적용되는 것도 변경되었다. 기존에는 forced로 설정한 encoding이 priority가 가장 높았다.

<request-encoding> 태그와 <postdata-encoding> 태그가 <request-encoding>로 통합되었으며, <request-url-encoding>이 추가되었다.

<response-encoding>은 변동이 없다. <request-url-encoding>은 HTTP header 의 Request line을 Parsing할 때만 적용되는 encoding으로 jeus-web-dd.xml에서는 설정할수 없다.

자세한 내용은 “JEUS Web Container 안내서”의 “3.3.2. 인코딩 설정”을 참조한다.

기존 설정의 경우 오직 WEBMain.xml에서 컨텍스트 그룹 단위로 세션의 세부 설정이 가능했으나(타임아웃 설정 제외) <session-config>설정을 통해 개별 컨텍스트 단위(jeus-web-dd.xml)로까지 세션의 세부 설정을 적용할 수 있도록 하였다.

또한 세션 서버 설정을 하였다 하여 모든 컨텍스트들이 무조건 세션 클러스터링에 참여하는 것이 아니라 <distributable>설정을 통해 세션 클러스터링 참여 여부를 개별적으로 적용할 수 있다.

컨텍스트, 컨텍스트 그룹, 컨테이너별 세션 설정은 차례대로 우선 순위를 가지며 계층적으로 Override하면서 사용될 수 있다.

자세한 내용은 “JEUS Web Container 안내서”의 “3.3.5. Session 설정”을 참조한다.

이전 버전에서는 중앙식 세션 서버를 설정할때 JEUSMain.xml, WEBMain.xml, 시스템 프로퍼티 모두를 같이 사용하는 설정의 복잡함으로 많은 동작 오류를 경험했다.

이를 방지하기 위해 모든 설정은 JEUSMain.xml으로 통합하며 노드 클러스터링을 전제로 동작하도록 한다.

JEUS 6.0에서 변경된 설정은 필수값을 요구하지 않으며 세션 서버의 상호 인식은 오직 노드 이름을 통하여 가능하다(기존 세션 서버의 이름 지정 및 IP, Port 지정 대신 JEUS의 노드 이름을 이용).

자세한 내용은 “JEUS Server 안내서”의 “10.2.2. 중앙 세션 서버의 설정”을 참조한다.

또한 JEUS 5의 세션 서버 설정으로부터 JEUS 6의 세션 서버 설정으로 변경하려면 “JEUS Server 안내서”의 “10.2.4. JEUS 5에서 JEUS 6로 설정 변환”을 참조한다.

기존 설정의 경우 백업 서버를 설정할 경우에 노드, 컨테이너의 Listen 포트 등 여러 가지를 고려해야 했고, 가장 적절한 백업 서버가 무엇인지 선택해야 하는 어려움이 있었다.

이를 해결하기 위해 특정 백업 서버 지정을 설정에서 제거하고 노드 클러스터링을 전제로 동작하도록 하였으며, 자동으로 가장 적절한 백업 대상을 찾는 기능을 추가하였다.

자세한 내용은 “JEUS Server 안내서”의 절 10.3.1. “분산 세션 서버의 백업 서버 선택 방식” 및 “JEUS Server 안내서”의 “10.3.2. 분산 세션 서버의 설정 ”을 참조한다.

또한 JEUS5의 분산 세션 서버 설정으로부터 JEUS 6의 분산 세션 서버 설정으로 변경하려면 “JEUS Server 안내서”의 “10.3.3. JEUS 5에서 JEUS 6로 설정 변환”을 참조한다.

기존에는 Datasource의 connection이 일정 시간 동안 사용되지 않을 경우, Timeout을 발생하게 하는 Operation Timeout이 제공되었다. 그러나, DB에 따라서 오동작하는 경우가 많았으며, connection 유실이 발생하기 때문에 이를 제거하었다. Operation Timeout 대신에 DBA Timeout 기능을 사용하길 권장한다. DBA Timeout은 “JEUS Server 안내서”의 절 8.3.4. “DB Session Kill 기능 : DBA 위임 데이터소스 (DBA Delegation Datasource)”를 참고한다.

Annotation을 이용한 프로그래밍의 도입으로 JEUSBuilder는 더 이상 제공하지 않는다.

기존에서 용도별로 따로 제공되던 콘솔 툴이 jeusadmin 하나로 통합되었다. jeusadmin의 자세한 사용법은 “JEUS Reference Book”의 “4.2. jeusadmin”을 참고한다.

이에 대한 자세한 설정 및 사용법은 “JEUS Reference Book”의 “5.3. EJB Ant Task”를 참고한다.

"JEUS_HOME\lib\endorsed"디렉터리가 추가 되었다.

이 디렉터리에는 JEUS 6 런타임이 JDK 환경에 영향을 받지 않게 하기 위해 Java 런타임이 JDK 기본 클래스들 보다 먼저 읽어들여야 하는 클래스들을 JAR 파일 형태로 묶여서 존재한다.

현재 포함된 라이브러리들은 다음과 같다.

이 파일들을 임의로 변경하게 되면 JEUS 6 런타임에 문제가 발생할 수 있다.

JEUS의 설정 XML에 다음과 같이 해당 Schema의 버전을 명시하도록 되었다. JEUS 6 에서 사용하는 Schema 버전은 6.0 버전이다.

<?xml version="1.0"?>
<jeus-system xmlns="http://www.tmaxsoft.com/xml/ns/jeus" version="6.0">
  ...
</jeus-system>