Rational Application
Developer V6.0.1에서
웹 프로젝트를 가져오거나 낡은 자원을
포함하는 작업공간이 열릴 때 Faces Client 런타임 자원이 자동으로 갱신됩니다.
WebSphere Studio
Application Developer V5.1.x에서
Rational Application
Developer V6.0.1로 웹 프로젝트를
가져오거나 작업공간을 열 때 Faces Client 런타임 자원을 최신 레벨로
갱신하도록 프롬프트됩니다.
자동으로 런타임
자원 갱신
웹 프로젝트에
대해 Faces Client 런타임 자원을
자동으로 갱신하려면 다음을 수행하십시오.
- WebSphere Studio
Application Developer V5.1.x에서
Faces Client 컨텐츠를 포함하는 웹 프로젝트(또는 작업공간)를
가져오십시오. 프로젝트 이주 창이 열립니다.
참고: 프로젝트 이주 창이 열리지 않는 경우 자동 빌드 환경 설정
설정이 사용 불가능할 수 있습니다. 프로젝트 탐색기에서
웹 프로젝트를 마우스 오른쪽 단추로 클릭하고 를 선택하십시오. 프로젝트 다시 빌드
프로세스가 프로젝트 이주 창을 엽니다.
- 작업공간에 Faces Client 컨텐츠를 갖는 다른 웹 프로젝트가 있는 경우
업그레이드되어야 하는 다른 모든 프로젝트에 이 선택사항 적용을
선택하면 모든 웹 프로젝트가 갱신됩니다.
- 다음 중 하나를 클릭하십시오.
- 예를 클릭하면 갱신을 자동으로 완료합니다.
- 나중을 클릭하면 갱신이 지연됩니다. 나중을
선택한 후 자동으로 런타임 자원을 갱신하려면 웹 프로젝트를 닫고 다시 열거나
웹 프로젝트를 다시 빌드하기 전에 Workbench를 다시 시작해야 합니다. 자동
빌드를 사용 불가능하게 한 경우 웹 프로젝트를 마우스 오른쪽 단추로 클릭하고
프로젝트 빌드를 선택하십시오.
- 수행 안함을 클릭하면 런타임 자원이 이전 레벨로 유지됩니다.
수행 안함을 선택하고 의도적으로 이전 레벨
런타임 자원에 머무르는 경우 갱신하도록 다시 프롬프트되지 않습니다.
나중에 필요한 경우
런타임 자원을 수동으로 갱신해야 합니다.
- 웹 프로젝트의 폴더에서 이름 지정 규칙이 com.ibm.dynwdo4jsmediators.<client-data-name>인
모든 클라이언트 데이터 중개자 클래스 패키지를 삭제하십시오.
com.ibm.dynwdo4jsmediators라는 패키지를 삭제하지 마십시오. 이 패키지에는
프로젝트에서 중개자 재생성을 위해 사용할 클라이언트 데이터에 대한
메타데이터(ecore 및 emap 파일)가 있습니다.
- 웹 프로젝트의 폴더에서 OdysseyBrowserFramework.properties 파일을 열고
EMAP_FILES 및 ECORE_FILES에 대한 항목을 삭제하십시오.
- 클라이언트 데이터 보기의 각 데이터 오브젝트에 대해 다음을 수행하십시오.
- 마우스 오른쪽 단추를 클릭하고 구성을 선택하십시오.
- 고급 탭에서 서버측 데이터에서
재생성을 클릭하여 데이터 오브젝트에 대한 모든 중개자를
다시 생성하십시오.
수동으로
런타임 자원 갱신
웹 프로젝트에 대해 Faces Client
런타임 자원을
수동으로 갱신하려면 다음을 수행하십시오.
- 웹 프로젝트의 Faces 런타임 자원 갱신의 수동으로 런타임 자원
갱신 단계를 완료하십시오.
- 위의 자동으로 런타임 자원 갱신 섹션의 4-6단계를
완료하십시오.
WebSphere Application Server V5.1에서
V6.0으로 Faces Client 컴포넌트가 들어있는 프로젝트의 대상 서버를
변경할 때 문제점이 발생할 수 있습니다.
WebSphere Application
Server V5.1에서 V6.0으로 Faces Client 컴포넌트가 들어있는 프로젝트의 대상
서버를 변경할 때 다음 두 가지 문제점이 발생할 수 있습니다.
- 이미 생성된 클라이언트 데이터 중개자 클래스가 더 이상 컴파일하지
않습니다. 한 번에 하나의 JSP가 재생성되어야 합니다.
- 루트 Java™ 소스 폴더에서
발견된 OdysseyBrowserFramework.properties 파일을 여십시오. 나중 사용을 위해 컨텐츠를 저장하십시오.
- OdysseyBrowserFramework.properties 파일에서 Faces Client 데이터가
들어있는 웹 프로젝트의 각 JSP에 대해 EMAP_FILES 및 ECORE_FILES 특성에
대한 <client-data-name>.ecore 및 <client-data-name>.emap 항목을 찾으십시오.
- 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
- 특성 파일을 저장하십시오.
- SP에서 클라이언트 데이터 오브젝트를 선택한 후 마우스 오른쪽 단추를 클릭하고 구성을 선택하십시오.
- 고급 탭에서 모두 재생성을
클릭하십시오. 현재 JSP의 모든 클라이언트 데이터에 필요한 모든 아티팩트가
다시 생성됩니다.
- 웹 프로젝트의 클라이언트 데이터를 포함하는 각 JSP에 대해 2-6단계를
반복하십시오.
- 클라이언트 데이터 중개자 클래스를 재생성한 후, 일부 중개자 클래스는 컴파일되지 않은 채로 남습니다. 이들은 V6.x의 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의 소스 보기를 수정하는 것입니다. 예를 들어
account라는 WDO의 경우,
- 루트 오브젝트에 대해 className 태그를 className="com.ibm.etools.wdo.DataObject(DynWDO`account`RootDataObject)"에서 className="commonj.sdo.DataObject(DynWDO`account`DataGraphRoot)"로 변경하십시오.
- 모든 하위 노드에 대해 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 핸들러 및 프로세서를 작성한 경우
해당 코드를 삭제하고 자동으로 생성된 프로세서 및 핸들러를 사용하는 것이
바람직합니다.
- 웹 프로젝트의 각 클라이언트 데이터 오브젝트에 새 Diff 핸들러 및
프로세서를 생성하십시오.
- 클라이언트 데이터 오브젝트를 선택하고, 마우스 오른쪽 단추를 클릭하고 구성을 선택하십시오.
- 고급 탭에서 모두 재생성을
클릭하십시오.
- 생성된 프로세서와 핸들러가 자동으로 호출되므로 Diff 프로세서 및
핸들러를 호출하기 위해 작성한 코드를 제거하십시오. 이 코드가
사용된 일반적인 예는 다음과 같은 명령 단추 컴포넌트에 대한 명령 이벤트의
경우입니다. 예를 들면,
String Diff = getClientData1().getDiffStr();
if (DiffProcessor.Synch(getRoot(), Diff) == true)
return "";
return "failure";
- 사용자가 작성한 이전의 사용자 정의 핸들러 및 프로세서에
해당하는 파일을 웹 프로젝트에서 제거하십시오.
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 프로세서 및 핸들러가 자동으로 생성되기 때문입니다. 이전 핸들러를 보존하는 것은
단지 일시적인 솔루션이므로 자동화된 핸들러를 사용할 것을 권장합니다.