Faces Client 구성요소와 함께 JavaServer Faces 자원 이주

JavaServer Faces JSP(JavaServer Page)의 Faces Client 구성요소를 포함하는 프로젝트를 WebSphere® Studio V5.1.x에서 작성한 경우, Faces Client 구성요소의 런타임 자원을 최신 레벨로 이주해야 합니다.

WebSphere Studio V5.1.x에서 작성한 Faces Client 구성요소와 함께 JavaServer Faces JSP를 포함하는 프로젝트를 V6.0에서 연 후, 다음을 수행해야 Faces Client 구성요소의 런타임 자원이 이주됩니다.
  1. JSP 파일을 새로 작성하고 모델로 클라이언트측 데이터 캐싱을 사용하는 기본을 선택하십시오. 이 JSP는 Rational® Web Developer가 모든 시스템 Java™ 아카이브(JAR) 파일을 최신 레벨로 이주하도록 하기 위해 임시로 필요합니다.
  2. 프로젝트 런타임 자원을 최신 레벨로 이주할 수 있음을 알리는 프롬프트가 표시됩니다. 이주를 완료하려면 를 선택하십시오. 중요: 아니오를 선택하거나 대화 상자를 취소할 경우, 프로젝트의 Faces Client 구성요소는 최신 레벨로 이주되지 않고 다시 프롬프트가 표시되지 않으며 새 도구 작업과 이전 런타임 JAR 파일 사이에 몇 가지의 심각한 문제점이 발생합니다.
  3. JSP 파일을 새로 작성한 후에 프로젝트에서 그 파일을 삭제할 수 있습니다.
  4. 클라이언트 데이터 영역에서 데이터 오브젝트를 선택하고 마우스 오른쪽 단추를 클릭한 다음 구성을 선택하십시오. 고급 탭에서 모두 재생성을 선택하십시오. 그러면 모든 중개자가 재생성됩니다.
    주: 서버측 데이터에서 재생성 단추는 사용하지 마십시오. 모두 재생성을 사용해야 합니다.
  5. 버전 5.12에는 더 이상 버전 6.0에서 사용되지 않은 WDO(WebSphere Data Object) 스키마 요소가 있습니다. 이러한 요소의 중개자 클래스는 재생성되지 않으므로 계속 컴파일 오류가 발생합니다. 이러한 중개자의 이름 지정 규칙은 *_DataGraphSchema_wdo4js_*.java입니다. 프로젝트에서 이 중개자 클래스를 삭제하여 이러한 컴파일 오류가 발생하지 않도록 하십시오.
Linux™ 플랫폼에서 작업 중이거나 영어 이외의 로케일을 사용 중일 경우: 위에 설명된 단계를 수행하여 WebSphere Studio V5.1.x에서 작성된 JavaServer Faces JSP의 Faces Client 구성요소를 포함하는 프로젝트를 이주하기 전에, 프로젝트를 V6.0으로 로드할 때 다음과 같은 오류 메시지가 표시될 수 있습니다.
<class_name>.java를 읽을 수 없어서
프로젝트를 빌드할 수 없습니다. 
V5.1.x 프로젝트의 클라이언트 데이터 중개자 클래스는 인코딩되지 않은 특수 문자를 포함할 수 있지만 Rational Web Developer V6.0의 중개자 클래스는 이러한 문자를 인코딩하므로 파일을 읽을 수 없습니다. 이러한 오류 메시지는 위에 설명된 단계를 수행하여 클라이언트 데이터를 재생성하면 중지됩니다. 그러나 단계에 따라 Faces Client 구성요소를 포함하는 프로젝트를 이주하기 전에, 먼저 작업공간을 빌드할 수 있도록 V6.0에 로드한 프로젝트에서 클라이언트 데이터 중개자 파일을 삭제해야 합니다. 클라이언트 데이터 중개자 파일을 삭제하려면 다음을 수행하십시오.
  1. 이름 지정 규칙 com.ibm.dynwdo4jsmediators.<client-data- name>을 가지고 있는 모든 클라이언트 데이터 중개자 클래스 패키지를 프로젝트에서 삭제하십시오.
  2. com.ibm.dynwdo4jsmediators 패키지는 삭제하지 마십시오. 이 패키지에는 프로젝트에서 중개자 재생성을 위해 사용할 클라이언트 데이터에 대한 메타데이터(ecore 및 emap 파일)가 있습니다.
  3. 중개자 패키지를 삭제하고 나면 프로젝트가 빌드됩니다. 이제 위에 설명한 이주 단계를 완료할 수 있습니다.

어떤 경우에는 중개자 생성 실패 메시지가 표시될 수 있습니다. 이 문제점을 해결하려면 OdysseyBrowserFramework.properties 파일을 편집하고 EMAP_FILES 및 ECORE_FILES 특성에 대한 항목을 삭제한 후 다시 시도하십시오.

주: Faces Client 구성요소를 포함하는 프로젝트의 대상 서버를 WebSphere Application Server V5.1에서 V6.0으로 변경할 때 문제가 발생할 수 있습니다.
Faces Client 구성요소를 포함하는 프로젝트의 대상 서버를 WebSphere Application Server V5.1에서 V6.0으로 변경할 때 발생할 수 있는 문제점은 두 가지입니다.
  • 이미 생성된 클라이언트 데이터 중개자 클래스는 더 이상 컴파일되지 않습니다. 따라서 이러한 클래스는 한 번에 하나의 JSP를 재생성해야 합니다. 이렇게 하려면 다음과 같이 수행하십시오.
    1. 루트 Java 소스 폴더에서 발견된 OdysseyBrowserFramework.properties 파일을 여십시오. 나중 사용을 위해 컨텐츠를 저장하십시오.
    2. OdysseyBrowserFramework.properties 파일에서, 프로젝트에 있는 Faces Client 데이터를 포함하는 JSP마다 EMAP_FILES 및 ECORE_FILES 특성에 대해 <client-data-name>.ecore 및 <client-data-name>.emap 항목을 찾으십시오.
    3. JSP의 클라이언트 데이터에 대해 일치하는 항목만 보관하고 다른 모든 항목은 삭제하십시오.
      예를 들어, 현재 페이지에 ACCOUNT라고 하는 클라이언트 데이터가 있고 특성 파일에 다음과 같은 항목이 있을 경우,
      EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap com\\ibm\\dynwdo4jsmediators/orders.emap
      항목에서 com\\ibm\\dynwdo4jsmediators/orders.emap를 삭제해야 합니다. 그러면 항목이 다음과 같이 표시됩니다.
      EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap
    4. 특성 파일을 저장하십시오.
    5. JSP의 클라이언트 데이터를 마우스 오른쪽 단추로 클릭하고 구성을 선택하십시오.
    6. 고급 탭을 선택하십시오. 모두 재생성 단추를 클릭하십시오. 그러면 현재 JSP의 모든 클라이언트 데이터에 필요한 모든 아티팩트가 재성성됩니다.
    7. 프로젝트에서 클라이언트 데이터를 포함하는 JSP마다 이 단계를 반복하십시오.

    프로젝트의 JSP에 대해 클라이언트 데이터 중개자 클래스를 재생성하면, 컴파일되지 않는 일부 중개자 클래스가 여전히 남아 있습니다. 이 중개자 클래스들은 더 이상 V6.0에서 SDO(Service Data Object)에 사용되지 않는 스키마 요소용 중개자입니다. 이러한 중개자의 이름 지정 규칙은 *_DataGraphSchema_wdo4js_*.java 및 *_RootDataObject_wdo4js_*.java입니다. 프로젝트에서 이 중개자 클래스를 삭제하여 이러한 컴파일 오류가 발생하지 않도록 하십시오.

    이주를 완료한 후, OdysseyBrowserFramework.properties 파일의 원래 컨텐츠를 복원하십시오.

  • WDO에 바인드된 트리 보기 Faces Client 구성요소는 프로젝트의 대상 서버를 WebSphere Application Server V6.0으로 변경한 후 서버에서 실행되지 않습니다.
    이에 대한 해결책은 모든 className 태그가 WDO DataObject 클래스 대신 SDO DataObject 클래스를 사용하도록 변경하기 위해 JSP의 소스 보기를 수정하는 것입니다. 예를 들어, WDO account의 경우 다음과 같습니다.
    1. 루트 오브젝트에 대해 className 태그를 className="com.ibm.etools.wdo.DataObject(DynWDO`account`RootDataObject)"에서 className="commonj.sdo.DataObject(DynWDO`account`DataGraphRoot)"로 변경하십시오.
    2. 모든 하위 노드에 대해 className 태그를 className="com.ibm.etools.wdo.DataObject(DynWDO`account`ACCOUNT)"에서 className="commonj.sdo.DataObject(DynWDO`account`ACCOUNT)"로 변경하십시오. 여기서 ACCOUNT는 데이터 노드의 이름입니다.
자동화된 Diff 핸들러 및 프로세서로 업그레이드: Diff 프로세서 및 핸들러는 이제 자동으로 생성됩니다. WebSphere Studio V5.1.x에서 Faces Client 구성요소에 대해 Diff 핸들러 및 프로세서를 작성한 경우, 해당 코드를 버리고 자동으로 생성되는 프로세서 및 핸들러를 사용하도록 하십시오. 이렇게 하려면 다음 단계를 수행하십시오.
  1. 새 Diff 핸들러 및 프로세서를 생성하십시오. 이렇게 하려면 프로젝트의 각 클라이언트 데이터 오브젝트에 대해 다음을 수행해야 합니다.
    1. 클라이언트 데이터 오브젝트를 선택하고 마우스 오른쪽 단추를 클릭한 후 구성을 선택하십시오.
    2. 고급 탭에서 모두 재생성을 선택하십시오.
  2. 생성된 프로세서와 핸들러가 자동으로 호출되므로, Diff 프로세스 및 핸들러를 호출하기 위해 작성한 코드를 제거하십시오. 이 코드가 사용된 일반적인 예는 명령 단추 구성요소에 대한 명령 이벤트의 경우입니다. 다음은 코드 예입니다.
    String Diff = getClientData1().getDiffStr();
    if (DiffProcessor.Synch(getRoot(), Diff) == true)
     return "";
    return "failure";
  3. 작성한 이전의 사용자 정의 핸들러 및 프로세서에 해당하는 파일을 프로젝트에서 제거하십시오.
V5.1.x용으로 작성된 사용자 정의 Diff 핸들러 및 프로세서 보존: 다음과 같이 수행하는 것이 바람직하지만 V5.1.x의 사용자 정의 Diff 핸들러 및 프로세서로 보존함과 동시에 V6.0에서 작동되도록 하려면 수정이 필요합니다. DiffHandler 인터페이스 및 DiffInfo 클래스가 변경되었기 때문입니다.
  • DiffHandler 인터페이스는 다음과 같이 변경되었습니다.
    • handle 메소드에서는 이제 DiffException 이외에 Exception도 발생합니다.
    • 새 find 메소드는 오브젝트를 찾기 위해 프레임워크에서 사용됩니다.
    • 새 getId 메소드는 디버깅을 위해 사용되며 프레임워크가 오브젝트 값을 인쇄할 수 있도록 허용합니다.

    find 및 getId 메소드는 생성된 DiffHandler에 의해 내부에서 사용됩니다. 사용자 정의 DiffHandler의 경우, 단지 인터페이스에 따르기 위해 빈 메소드를 구현하면 됩니다. 이러한 메소드는 프레임워크에서 호출되지 않습니다.

    변경된 DiffHandler 인터페이스는 다음과 같습니다.
    public interface DiffHandler
     {
       public void   handle(DiffInfo Diff) throws DiffException, Exception;
       public Object find  (DiffInfo Diff) throws DiffException, Exception;
       public String getId (DiffInfo Diff, boolean Original);
     }
  • DiffInfo 클래스는 다음과 같이 변경되었습니다.
    • 메소드 ArrayList getAncestors()가 메소드 DiffInfo getParent()로 대체되었습니다. 이 DiffInfo getParent() 메소드는 최상위 트리에서 각 오브젝트의 정보에 대해 가장 쉽게 순환 방식으로 액세스할 수 있는 방법을 제공합니다.
    • 메소드 getCurrent() 및 getOriginal()은 이제 EObject 오브젝트 대신 DataObject 오브젝트를 리턴합니다. 반드시 DataObject 오브젝트를 사용하도록 코드를 변경할 필요는 없습니다. 그러나 DataObject 인터페이스는 EObject를 사용하는 것보다 더 쉽고 직관적입니다. 레거시 코드를 위해 쉽게 DataObject 오브젝트를 EObject 오브젝트로 캐스트할 수 있습니다.
    • 오브젝트가 적용되는 특성 이름을 식별하기 위해 새 메소드 String getPropertyName()이 추가되었습니다. 이는 예를 들어, 지정된 클래스에 동일 유형의 두 특성이 있을 경우 중요합니다. 이전 DiffInfo 클래스에서는 코드를 두 특성 사이에서 구별할 수 없었습니다.
    DiffInfo 클래스는 이제 다음과 같습니다.
    public class DiffInfo
     {
       public char       getCrud()
       public DataObject getCurrent()
       public String     getEClassName()
       public DataObject getOriginal()
       public String     getPropertyName()
       public DiffInfo   getParent()
     }
    주: DiffInfo 클래스는 더 이상 공용으로 지원되지 않습니다. Diff 프로세서 및 핸들러가 자동으로 생성되기 때문입니다. 이전 핸들러를 보존하는 것은 단지 일시적인 솔루션이므로 자동화된 핸들러를 사용할 것을 권장합니다.
V6.0에서 Faces Client 구성요소에 대한 변경사항:
  • WebSphere Application Server V6.0을 지원합니다.
  • WebSphere Application Server V6.0에서의 SDO(Service Data Objects)를 지원합니다.
  • EGL 데이터는 이제 클라이언트 데이터로 지원됩니다.
  • Diff 프로세서 및 핸들러가 자동으로 생성됩니다.
  • 다음 클라이언트 구성요소에 대해 새 이벤트가 있습니다.
    • TabbedPanel: onInitialPageShow
    • Tree: onNodeExpand, onNodeCollapse, onExpand, onCollapse
    • DataGrid: onPage, onSort, onFilter
관련 태스크
포틀렛 프로젝트에서의 Faces 자원 이주
이용약관 | 피드백
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.