IBM Rational Application Developer per Windows e Linux, Versione 6.0 - Guida alla migrazione
Capitolo 1. Migrazione da WebSphere Studio V5.1, 5.1.1 o 5.1.2
Capitolo 2. Aggiornamento delle risorse di runtime Faces per i progetti Web da Rational Application Developer V6.0
Capitolo 3. Aggiornamento delle risorse di runtime Faces per i progetti portlet da Rational Application Developer V6.0
Capitolo 4. Migrazione di progetti J2EE
Capitolo 5. Migrazione agli strumenti Portal in Rational Application Developer V6.0
Migrazione dei portlet WebSphere Portal da V4.2 a V5.x
Aggiornamento delle risorse di runtime Faces in un progetto portlet
Capitolo 6. Modifiche negli ambienti di test di WebSphere
Questa documentazione fornisce istruzioni per la migrazione da WebSphere
Studio Application Developer V5.1.x a Rational Application
Developer V6.0.
Ulteriori informazioni sono disponibili nei seguenti argomenti:
Le informazioni relative all'utilizzo di Rational Application
Developer sono disponibili nella guida in linea.
Per documentazione aggiornata, fare riferimento alla pagina www.ibm.com/developerworks/rational.
Per informazioni sulla migrazione dalle versioni precedenti di WebSphere
Studio a v5.x o sulla migrazione da VisualAge per Java a WebSphere
Studio, visitare il sito www.ibm.com/software/awdtools/studioappdev/support/
e ricercare "guida alla migrazione".
Per eseguire la migrazione da WebSphere Studio V5.1.x:
- Prima dell'installazione, leggere le informazioni sulla compatibilità con Eclipse V2.x e WebSphere
Studio V5.1.x. La compatibilità con le versioni
precedenti non è supportata per i progetti di applicazione portlet migrati
da Portal Toolkit V5.0.2.2 con WebSphere Studio
V5.1.2.
- Eseguire il backup dello spazio di lavoro di WebSphere Studio
V5.1.x.
- Installare Rational Application Developer. Fare riferimento alla
Guida all'installazione (file install.html) disponibile
nella directory principale del primo CD del prodotto.
- Consigliato: per impostazione predefinita, la prima volta
che si avvia Rational Application Developer, viene richiesto di confermare che
si desidera utilizzare uno spazio di lavoro denominato
rationalsdp6.0\workspace. Ciò significa che la finestra di
dialogo Utilità di avvio spazio di lavoro indica una directory che non
corrisponde allo spazio di lavoro WebSphere Studio. Per esplorare il
nuovo ambiente prima di migrare il vecchio spazio di lavoro, accettare
l'impostazione predefinita o specificare un nuovo nome di directory
quando si avvia Rational Application Developer. Si consiglia di
eseguire questa operazione, ad esempio, per creare uno o due progetti di test,
individuare il nuovo progetto (Guida ->
Benvenuti), eseguire alcune nuove esercitazioni (Guida
-> Galleria di esercitazioni) o provare alcuni nuovi esempi
(Guida -> Galleria di esempi).
- Migrare i progetti alla versione 6.0. I progetti creati in
WebSphere Studio V5.1.x possono essere migrati automaticamente a
V6.0 come segue:
- Migrazione di uno spazio di lavoro: quando si è pronti
ad eseguire la migrazione dello spazio di lavoro V5.1.x, avviare
Rational Application Developer con il vecchio spazio di lavoro. Un
indicatore di avanzamento conferma che i progetti vengono migrati
automaticamente.
Note: Durante la migrazione dello spazio di lavoro, si
apre una finestra di dialogo Problemi con il messaggio
Impossibile ripristinare il layout del workbench. Motivo:
Problemi durante il ripristino del workbench. I messaggi di
errore non hanno alcun impatto sulla migrazione dello spazio di lavoro.
Annotare il nome della prospettiva che non può essere ripristinata facendo
clic sul pulsante Dettagli nella finestra di dialogo di errore,
quindi facendo clic su OK per chiudere la finestra di
dialogo.
Per ripristinare la prospettiva:
- Chiudere la prospettiva selezionando Finestra ->
Chiudi prospettiva
- Riaprire la prospettiva selezionando Finestra ->
Apri prospettiva.
- Nota:
- Per i progetti EGL (Enterprise Generation Language) che hanno utilizzato
la prospettiva Web EGL in WebSphere Studio V5.1.2:
questa prospettiva è stata rimossa in Rational Application Developer
V6.0. Tutti i progetti EGL vengono migrati senza questa
prospettiva in Rational Application Developer V6.0. Se è
stata utilizzata la prospettiva Web EGL, procedere come segue:
- Chiudere la prospettiva Web EGL.
- Abilitare le funzioni EGL nelle Preferenze (Finestra ->
Preferenze). Per ulteriori informazioni
sull'abilitazione delle funzioni EGL, fare riferimento alla guida in
linea.
- Selezionare Finestra -> Apri prospettiva e
scegliere la prospettiva Web.
- Migrazione dei progetti caricati da un sistema SCM (source code
management): i progetti da WebSphere Studio 5.1.x
che esistono in un sistema SCM vengono migrati automaticamente a V6.0
quando vengono caricati in Rational Application Developer.
- Migrazione dei progetti importati utilizzando Project
Interchange: i progetti esportati da WebSphere Studio
V5.1.2 o V5.1.1 e importati in Rational
Application Developer V6.0 utilizzando la funzione Project Interchange
vengono migrati automaticamente a V6.0. La funzione Project
Interchange era disponibile in WebSphere Studio V5.1.2 ed era un
plugin facoltativo per V5.1.1.
Note:
- Se si utilizza Portal Toolkit V5.0.2.2 con
WebSphere Studio V5.1.2 per sviluppare i progetti portlet,
lo spazio di lavoro viene migrato automaticamente affinché sia compatibile
con Rational Application Developer. Per ulteriori informazioni, fare
riferimento a Capitolo 5, Migrazione agli strumenti Portal in Rational Application Developer V6.0.
- Per ciascun progetto V5.1.x migrato a V6.0, il
programma di migrazione aggiunge automaticamente un file .compatibility
alla cartella del progetto in V6.0. Questo file viene utilizzato
per la compatibilità con le versioni precedenti con WebSphere Studio
V5.1.x. Non modificare o eliminare questo file.
Per ulteriori informazioni, fare riferimento alla sezione sulla compatibilità con WebSphere Studio
V5.1.x.
Importante:
- Se allo spazio di lavoro che si desidera migrare sono associate
configurazioni di avvio di debug, alcune configurazione di avvio non verranno
migrate automaticamente. Per informazioni su come ripristinare le
configurazioni di avvio in uno spazio di lavoro migrato, fare riferimento a Modifiche al debugger in V6.0.
- Se il debugger XSLT o il debugger EGL sono stati utilizzati nei progetti
dello spazio di lavoro migrato, è necessario modificare il JRE (Java
runtime environment) installato con Rational Application Developer
V6.0. Per i dettagli su come apportare questa modifica, fare
riferimento a Modifiche al debugger in V6.0.
- Se si dispone di programmi sviluppati utilizzando EGL (Enterprise
Generation Language) migrati a V6.0, tenere presente che nella versione
6.0 esistono nuove parole riservate per EGL. Se si utilizzano
queste parole come nomi di variabili o nomi di parti, è necessario
modificarle. Fare riferimento a Parole EGL riservate in V6.0
- Il driver DB2 Net JDBC non è supportato in Rational Application
Developer V6.0. Se le connessioni JDBC sono state create
utilizzando il driver DB2 Net JDBC, non sarà possibile riconnettersi a
Rational Application Developer V6.0. Per utilizzare uno dei
driver JDBC supportati, è necessario modificare la connessione. Per
ulteriori informazioni sui driver JDBC supportati in V6.0, fare
riferimento alla guida in linea.
- Se il contenuto file Web o XML è stato migrato da WebSphere Studio
Application Developer V5.1.x, in cui è stato utilizzato
l'insieme di caratteri Shift_JIS e sono stati inclusi i caratteri
selezionati dal fornitore, è necessario specificare l'insieme di
caratteri Windows-31J.
- Se con WebSphere Studio Application Developer V5.1.x sono
stati installati plugin del fornitore, è necessario procurarsi i plugin
corrispondenti per V6.0 e reinstallarli.
- Se con l'installazione di Rational Application Developer sono stati
installati ambienti di test dell'unità WebSphere V5.x di
livello precedente e se è stato utilizzato il servizio di messaggistica
incorporato, aggiornare il servizio installando la versione fornita con
Rational Application Developer. Per i dettagli sull'installazione
del servizio di messaggistica incorporato, fare riferimento alla guida
all'installazione.
- Se si utilizzano funzioni che richiedono Agent Controller, aggiornare tali
funzioni installando la versione fornita con Rational Application
Developer. Per i dettagli, fare riferimento alla guida
all'installazione.
- Per eseguire la migrazione da VisualAge Generator, consultare il manuale
VisualAge Generator to Enterprise Generation Language (EGL) Migration
Guide, disponibile in formato PDF nella sezione relativa
all'installazione e alla migrazione dell'argomento "Accessing the
VisualAge Generator to EGL Migration Guide" della guida in linea. La
copia più recente è disponibile su http://www.ibm.com/developerworks/rational/library/egldoc.html.
Quando si apre per la prima volta uno spazio di lavoro WebSphere Studio
V5.1.x in Rational Application Developer, lo spazio viene
migrato automaticamente. Una volta migrato, non è più possibile
aprire lo spazio di lavoro in WebSphere Studio Application Developer.
Tuttavia, i progetti dello spazio di lavoro V6.0 possono ancora essere
condivisi con WebSphere Studio V5.1.x, utilizzando un sistema
SCM (source code management) (ad esempio Rational ClearCase) importando ed
esportando il progetto mediante Project Interchange, o mediante
l'importazione di archivi e l'esportazione di progetti.
Importante: le applicazioni portlet da Portal Toolkit
V5.0.2.2 migrate agli strumenti del portale in Rational
Application Developer V6.0 non sono compatibili.
- Nota:
- Le informazioni di seguito riportate non vengono applicate ai progetti di
applicazione portlet.
I progetti V5.1.x esistenti caricati da un sistema SCM o da
un altro programma di sviluppo in Project saranno compatibili per la
condivisione con V5.1.x, se non viene effettuata una
delle seguenti azioni:
- Alterazione dei metadati di compatibilità aggiunti al file
.project e al file
.compatiblity creati dallo strumento di migrazione.
- Eliminazione del file
.compatibility da questi progetti.
- Eseguire l'azione "Rimuovi compatibilità" su un progetto
applicazione enterprise (se l'applicazione enterprise o uno dei relativi
moduli o progetti di utilità deve essere compatibile con WebSphere Studio
Application Developer V5.1.x).
Un file .compatibility viene creato automaticamente nella directory
del progetto quando un progetto V5.1.x viene aperto nello spazio
di lavoro Rational Application Developer V6.0. Il file
.compatibility viene utilizzato da Rational Application Developer per
tracciare la data/ora delle risorse del progetto, quando tali risorse vengono
migrate. Si consiglia di non modificare o eliminare questo file.
Per informazioni sulla disabilitazione della compatibilità con WebSphere
Studio Application Developer V5.1.x, fare riferimento a Disabilitazione della compatibilità con WebSphere Studio V5.1.x.
Considerazioni su Eclipse
Questa versione di Rational Application Developer si basa su Eclipse
V3.0. Se si sviluppano i plug-in, è necessario acquisire
informazioni sulle modifiche alla piattaforma prima della migrazione.
Per i dettagli, fare riferimento al file readme nella
sottodirectory eclipse\readme del percorso di installazione di Rational
Application Developer V6.0. Le sezioni del file readme di
interesse per la migrazione sono:
- Compatibility with Previous Releases
- Upgrading Workspace from a Previous Release
- Interoperability with Previous Releases
Compatibilità dei progetti J2EE
La compatibilità dei progetti creati in WebSphere Studio
V5.1.x con Rational Application Developer V6.0 è
abilitata per mezzo dei metadati automaticamente aggiunti ai file
.project, quando si migra lo spazio di lavoro
V5.1.x. Allo stesso modo, se si crea un nuovo modulo o
applicazione J2EE 1.2 o 1.3 in Rational Application Developer
V6.0, i metadati di generazione vengono aggiunti automaticamente al
file
.project per la compatibilità con V5.1.x. Non
modificare o eliminare queste informazioni direttamente.
- Nota:
- I metadati di compatibilità generano la visualizzazione o la registrazione
di messaggi sui "generatori mancanti" quando un nuovo modulo o applicazione
J2EE 1.2 e J2EE 1.3 creati in V6.0 vengono utilizzati in
WebSphere Studio Application Developer V5.1.x, laddove i
generatori V6.0 non sono disponibili. Questi messaggi sono
normali ed è possibile ignorarli.
Fino a quando sono presenti metadati di compatibilità, verranno
visualizzati messaggi relativi a "generatori mancanti", quando i progetti
Rational Application Developer V6.0 vengono ricaricati in WebSphere
Studio V5.1.x. Di seguito viene riportato un esempio di
messaggio relativo a un "generatore mancante":
!ENTRY org.eclipse.core.resources 2 1 Sep 06, 2004 19:55:20.592
!MESSAGE Skipping builder com.ibm.wtp.j2ee.LibCopyBuilder for project Test60EARWeb.
Il generatore non è presente nell'installazione o appartiene a un progetto mancante o disabilitato.
Questi messaggi sono normali ed è possibile ignorarli. Quando si
è certi che non sia più necessario gestire un determinato progetto in
WebSphere Studio V5.1.x, è possibile arrestare i messaggi disabilitando la compatibilità con le versioni
precedenti per quel progetto.
Importante: nuovi progetti di specifica J2EE 1.2 o
1.3 creati in V6.0 sono compatibili con WebSphere Studio
V5.1.x, ma, una volta caricato il progetto in WebSphere Studio,
per poter gestire il progetto è necessaria una procedura manuale.
Questa procedura è necessaria perché le destinazioni di runtime sui
nuovi progetti di specifica J2EE 1.2 o 1.3 creati in 6.0
non sono direttamente compatibili con i server di destinazione in
V5.1.x. La procedura manuale dopo il caricamento di un
nuovo progetto V6.0 in V5.1.x è la seguente:
- Aprire il file .classpath per ciascun progetto J2EE con
un file
.classpath.
- Eliminare le voci del percorso classi di seguito riportate dal file
.classpath, quindi salvare e chiudere il file.
-
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/
org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere v5.1 JRE"/>
-
<classpathentry kind="con"
path="com.ibm.wtp.server.java.core.container/
com.ibm.etools.websphere.runtime.core.runtimeTarget.v51/was.base.v51"/>
- Verificare che il supporto di destinazione del server sia abilitato nella
pagina delle preferenze J2EE. Selezionare Finestra ->
Preferenze -> J2EE e confermare che l'opzione
Abilita supporto server di destinazione sia selezionata in
"Supporto assegnazione server di destinazione".
- Fare clic con il tasto destro del mouse sul progetto e selezionare
Proprietà -> J2EE.
- Selezionare il server di destinazione corrispondente per la destinazione
di runtime del progetto (ad esempio, WebSphere Application Server V5.1
utilizzando l'ambiente di runtime JDK 1.4) e fare clic su
OK.
- Il server di destinazione selezionato sarà compatibile per Rational
Application Developer V6.0 e WebSphere Studio Application Developer
V5.1.x. Una volta sottoposte a commit le modifiche nel
sistema SCM, i progetti J2EE saranno interscambiabili tra V5.1.x
e V6.0 utilizzando un sistema SCM.
- Nota:
- Se il server di destinazione è impostato di nuovo in Rational Application
Developer V6.0, la compatibilità dei progetti J2EE andrà perduta
e sarà necessario ristabilirla.
Compatibilità del diagramma UML
I diagrammi UML presenti in WebSphere Studio Application Developer
V5.1.x sono compatibili e possono essere aperti in modalità
di sola lettura in Rational Application Developer V6.0. In
V6.0, la procedura guidata Migrazione J2EE consente di migrare
automaticamente i diagrammi UML creati nei progetti J2EE V5.1.x
durante la migrazione della struttura del progetto J2EE. Una volta
migrati, i diagrammi UML possono essere modificati in Rational Application
Developer V6.0.
- Nota:
- I diagrammi UML migrati in uno spazio di lavoro o creati in Rational
Application Developer V6.0 non possono essere aperti in WebSphere
Studio Application Developer V5.1.x.
La compatibilità con WebSphere Studio Application Developer
V5.1.x può essere completamente rimossa da un progetto
applicazione enterprise creato in Rational Application Developer V6.0 o
da un progetto applicazione enterprise migrato da una versione precedente di
WebSphere Studio. È necessario disabilitare la compatibilità con
WebSphere Studio V5.1.x solo se si è certi che il progetto
applicazione enterprise non deve essere più interagibile o compatibile con
V5.1.x.
Per rimuovere la compatibilità con WebSphere Studio Application
Developer V5.1.x:
- Fare clic con il tasto destro del mouse su un progetto applicazione
enterprise e selezionare l'opzione di menu Rimuovi
compatibilità dal menu a comparsa.
- Si apre una finestra di dialogo in cui viene richiesto di confermare la
rimozione della compatibilità con le versione precedenti del progetto
applicazione enterprise e di tutti i moduli e dei progetti di utilità
nidificati nel progetto.
- Fare clic su Sì per continuare con l'operazione di
rimozione della compatibilità.
Una volta eseguita l'operazione di rimozione della compatibilità,
il progetto applicazione enterprise e tutti i moduli e i progetti di
utilità nidificati nel progetto applicazione enterprise non sono più
compatibili con WebSphere Studio Application Developer
V5.1.x.
Le risorse di runtime di JavaServer Faces originariamente fornite con
WebSphere Studio Application Developer V5.1.x sono state
aggiornate per Rational Application Developer V6.0.1. Se
si desidera continuare lo sviluppo in progetti Web creati con la versione
precedente del prodotto, si consiglia di aggiornare le risorse di runtime
Faces all'ultimo livello.
In Rational Application Developer V6.0.1, gli aggiornamenti
alle risorse di runtime Faces vengono effettuati automaticamente quando viene
importato un progetto o quando viene aperto uno spazio di lavoro che contiene
risorse obsolete. Dopo aver importato un progetto Web o aver aperto uno
spazio di lavoro da WebSphere Studio Application Developer
V5.1.x in Rational Application Developer V6.0.1,
verrà richiesto di aggiornare le risorse di runtime Faces all'ultimo
livello.
Aggiornamento automatico delle risorse di runtime
Per aggiornare le risorse di runtime Faces automaticamente per i
progetti Web, procedere come segue:
- Importare un progetto Web (o uno spazio di lavoro) contenente dati Faces
da WebSphere Studio Application Developer V5.1.x. Viene
aperta la finestra Migrazione progetto.
- Nota:
- Se la finestra Migrazione progetto non viene visualizzata, probabilmente
l'impostazione di generazione automatica è disabilitata. In
Esplora progetti, selezionare il progetto Web con il tasto destro del mouse e
scegliere Genera -> Progetto; il processo di
rigenerazione di un progetto apre la finestra Migrazione progetto.
- Se si dispone di altri progetti Web con contenuto Faces nello spazio di
lavoro, selezionare l'opzione Applica questa scelta a tutti i
progetti che devono essere aggiornati in modo che vengano aggiornati
tutti i progetti Web.
- Selezionare una delle seguenti opzioni:
- Sì per completare automaticamente
l'aggiornamento.
- Dopo per aggiornare in un secondo momento. Se si
seleziona Dopo, per aggiornare le risorse di runtime
automaticamente sarà necessario chiudere e riaprire il progetto Web o
riavviare il workbench prima di rigenerare il progetto Web. Se
l'operazione di generazione automatica è deselezionata, selezionare il
progetto Web con il tasto destro del mouse e selezionare Genera
progetto.
- Mai per lasciare le risorse di runtime al livello
inferiore. Se si seleziona Mai per non aggiornare
intenzionalmente le risorse di runtime, non verrà richiesto ancora di
aggiornarle. In seguito, qualora fosse necessario, le risorse di
runtime dovranno essere aggiornate manualmente.
- Nota:
- Se sono state create JSP Faces contenenti componenti del client Faces,
sarà necessario aggiornare separatamente le risorse di runtime dei
componenti del client Faces all'ultimo livello. Consultare la
sezione Aggiornamento delle risorse di runtime Faces Client in un progetto Web.
Aggiornamento manuale delle risorse di runtime
Per aggiornare le risorse di runtime Faces manualmente per i
progetti Web, procedere come segue:
- Importare il progetto Web esistente con contenuto Faces in uno spazio di
lavoro Rational Application Developer V6.0.1.
- Creare un nuovo progetto Web (o, se si utilizza EGL, creare un nuovo
progetto Web EGL) chiamato JSF601. Questo progetto verrà
utilizzato solo come origine per le ultime risorse di runtime; può
essere eliminato al termine dell'aggiornamento.
- In Esplora progetti, selezionare con il tasto destro del mouse il progetto
JSF601 e scegliere Proprietà dal menu.
- Scegliere Funzioni progetto Web e selezionare Aggiungi
componenti di base Faces e Aggiungi Faces Client Framework,
quindi scegliere OK.
- Se si utilizza EGL, creare un file di pagina JSF come
segue:
- Selezionare la cartella WebContent del nuovo progetto Web EGL.
- Selezionare Nuovo -> Altro -> File
JSP Faces.
I file eglintdebug.jar e
eglintdebugsupport.jar sono stati aggiunti al
progetto.
- Per ciascun progetto Faces esistente da aggiornare, procedere come
segue:
- In Esplora progetti, espandere un progetto esistente in modo da
visualizzare i file nella cartella WebContent/WEB-INF/lib/. Individuare
ed eliminare i seguenti file JAR in questa directory:
- eglintdebug.jar (solo EGL)
- eglintdebugsupport.jar (solo EGL)
- fda.jar (solo EGL)
- fdaj.jar (solo EGL)
- jsf-api.jar
- jsf-ibm.jar
- jsf-impl.jar
- odc-jsf.jar
- Individuare ed aprire il file
WebContent/WEB-INF/faces-config.xml. Aggiungere i seguenti
elementi nel file di configurazione, se non sono già presenti:
<lifecycle>
<phase-listener>com.ibm.faces.webapp.ValueResourcePhaseListener</phase-listener>
</lifecycle>
<application>
<variable-resolver>com.ibm.faces.databind.SelectItemsVarResolver</variable-resolver>
<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
</application>
- Per tutti i file JAR eliminati, copiare il file JAR dello stesso nome
dalla directory WebContent/WEB-INF/lib del progetto JSF601 e
incollarlo nel progetto originale nello stesso percorso. Alcune
configurazioni non richiedono che tutti questi file siano contenuti nel
progetto; non copiare i file JAR non presenti nel progetto
originale.
- Aprire il descrittore di distribuzione web.xml nel progetto
originale e aggiungere quanto segue alla configurazione:
<context-param>
<param-name>com.ibm.ws.jsf.JSP_UPDATE_CHECK</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>com.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP</param-name>
<param-value>true</param-value>
</context-param>
- Se il progetto originale utilizzava WebSphere Data Objects (WDO) per
qualsiasi accesso ai dati, procedere come segue:
- Nel progetto originale, scegliere File ->
Nuovo -> File JSP Faces per creare un nuovo file
temporaneo JSP Faces.
- Trascinare un componente elenco di record relazionali dal cassetto Dati
della tavolozza nella pagina.
- Scegliere una qualsiasi connessione e origine dati e selezionare
Fine. I dati selezionati non sono importanti. Questo
processo genererà qualsiasi configurazione necessaria per continuare con
l'uso di WDO in questo progetto.
- Eliminare i file JSP temporanei.
- Se si utilizza EGL, fare clic sul nome di ciascun progetto Web
EGL e scegliere Genera; quindi, se il progetto non viene
generato automaticamente, scegliere Progetto -> Genera
tutto.
- Eliminare il progetto Web JSF601.
Le risorse di runtime di JavaServer Faces Client che originariamente
venivano fornite con WebSphere Studio Application Developer
V5.1.x sono state aggiornate per Rational Application Developer
V6.0.1. Se si desidera continuare lo sviluppo in progetti
Web creati con la versione precedente del prodotto, si consiglia di aggiornare
le risorse di runtime Faces Client all'ultimo livello.
In Rational Application Developer V6.0.1, gli aggiornamenti
alle risorse di runtime del client Faces vengono effettuati automaticamente
quando viene importato un progetto o quando viene aperto uno spazio di lavoro
che contiene risorse obsolete. Dopo aver importato un progetto Web o
aver aperto uno spazio di lavoro da WebSphere Studio Application Developer
V5.1.x in Rational Application Developer V6.0.1,
verrà richiesto di aggiornare le risorse di runtime del client Faces
all'ultimo livello.
Aggiornamento automatico delle risorse di runtime
Per aggiornare le risorse di runtime del client Faces
automaticamente per i progetti Web, procedere come segue:
- Importare un progetto Web (o uno spazio di lavoro) contenente dati Faces
Client da WebSphere Studio Application Developer V5.1.x.
Viene aperta la finestra Migrazione progetto.
- Nota:
- Se la finestra Migrazione progetto non viene visualizzata, probabilmente
l'impostazione di generazione automatica è disabilitata. In
Esplora progetti, selezionare il progetto Web con il tasto destro del mouse e
scegliere Genera -> Progetto; il processo di
rigenerazione di un progetto apre la finestra Migrazione progetto.
- Se si dispone di altri progetti Web con contenuto Faces Client nello
spazio di lavoro, selezionare l'opzione Applica questa scelta a
tutti i progetti che devono essere aggiornati in modo che vengano
aggiornati tutti i progetti Web.
- Selezionare una delle seguenti opzioni:
- Sì per completare automaticamente
l'aggiornamento.
- Dopo per aggiornare in un secondo momento. Se si
seleziona Dopo, per aggiornare le risorse di runtime
automaticamente sarà necessario chiudere e riaprire il progetto Web o
riavviare il workbench prima di rigenerare il progetto Web. Se
l'operazione di generazione automatica è deselezionata, selezionare il
progetto Web con il tasto destro del mouse e selezionare Genera
progetto.
- Mai per lasciare le risorse di runtime al livello
inferiore. Se si seleziona Mai per non aggiornare
intenzionalmente le risorse di runtime, non verrà richiesto ancora di
aggiornarle. In seguito, qualora fosse necessario, le risorse di
runtime dovranno essere aggiornate manualmente.
- Dalla cartella Risorse Java -> JavaSource nel
progetto Web, eliminare tutti i pacchetti di classi di mediazione con nome
com.ibm.dynwdo4jsmediators.<client-data-name>.
Non eliminare il pacchetto
com.ibm.dynwdo4jsmediators. Questo pacchetto contiene
metadati (file ecore ed emap) per i dati client nel progetto che verranno
utilizzati per rigenerare i mediatori.
- Dalla cartella Risorse Java -> JavaSource nel
progetto Web, aprire il file OdysseyBrowserFramework.properties ed
eliminare le voci per EMAP_FILES e ECORE_FILES.
- Per ciascun oggetto dati nella vista Dati client:
- Fare clic con il tasto destro del mouse e selezionare
Configura.
- Nella scheda Avanzate, scegliere Rigenera dai dati del
server per rigenerare tutti i mediatori per l'oggetto dati.
Aggiornamento manuale delle risorse di runtime
Per aggiornare le risorse di runtime del client Faces
manualmente per i progetti Web, procedere come segue:
- Completare le istruzioni riportate nella sezione Aggiornamento
manuale delle risorse di runtime in Aggiornamento delle risorse di runtime Faces in un progetto Web.
- Completare i punti 4-6 della sezione Aggiornamento automatico delle
risorse di runtime precedente.
È possibile che possano verificarsi dei problemi durante la
modifica del server di destinazione di un progetto contenente componenti del
client Faces da WebSphere Application Server V5.1 a
V6.0.
Inoltre, possono verificarsi due problemi durante la modifica del server di
destinazione di un progetto contenente componenti del client Faces da
WebSphere Application Server V5.1 a V6.0:
- Le classi del mediatore dati client già generate non verranno più
compilate. Dovranno essere rigenerate con una JSP alla volta:
- Aprire il file OdysseyBrowserFramework.properties trovato nella
cartella principale dell'origine Java. Salvare il contenuto
affinché possa essere utilizzato in seguito.
- Nel file OdysseyBrowserFramework.properties, per ciascuna JSP Faces
nel nuovo progetto Web contenente dati client, trovare le voci
<client-data-name>.ecore e <client-data-name>.emap
per le proprietà EMAP_FILES e ECORE_FILES.
- Mantenere solo le voci corrispondenti per i dati client nel JSP ed
eliminare tutte le altre voci.
Ad esempio, se la pagina corrente contiene i dati client ACCOUNT e il file
delle proprietà ha una voce simile a:
EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap com\\ibm\\dynwdo4jsmediators/orders.emap
eliminare com\\ibm\\dynwdo4jsmediators/orders.emap da
questa voce. La voce verrà visualizzata come:
EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap
- Salvare il file delle proprietà.
- Selezionare un oggetto dati client in una JSP con il tasto destro del
mouse e scegliere Configura.
- Nella scheda Avanzate, scegliere Rigenera
tutto. In tal modo tutte le risorse necessarie per tutti i dati
client nella JSP corrente verranno rigenerati.
- Ripetere i punti 2-6 per ciascuna JSP contenente i dati client nel
progetto Web.
- Dopo aver rigenerato le classi del mediatore dati client, saranno presenti
ancora alcune classi di mediatore non compilate. Queste rappresentano i
mediatori per gli elementi di schema non più utilizzate negli SDO (Service
Data Objects) in V6.x ed utilizzano la convenzione di denominazione
*_DataGraphSchema_wdo4js_*.java and
*_RootDataObject_wdo4js_*.java. Eliminare queste classi di
mediazione dal progetto Web per prevenire tali errori di compilazione.
- Una volta che l'aggiornamento viene completato correttamente la
migrazione, ripristinare il contenuto originale del file
OdysseyBrowserFramework.properties.
- I componenti client Faces della vista ad albero associati a WDO non
possono essere eseguiti sul server dopo aver modificato il server di
destinazione del progetto in WebSphere Application Server V6.0.
La soluzione consiste nel modificare la vista Origine della JSP in modo da
cambiare tutti i tag className affinché utilizzino una classe SDO
DataObject invece della classe WDO DataObject. Ad esempio, per un WDO
chiamato account:
- Per l'oggetto principale, modificare il nome del tag className da
className="com.ibm.etools.wdo.DataObject(DynWDO`account`RootDataObject)"
in
className="commonj.sdo.DataObject(DynWDO`account`DataGraphRoot)".
- Per tutti i nodi secondari, modificare il tag className da
className="com.ibm.etools.wdo.DataObject(DynWDO`account`ACCOUNT)"
a
className="commonj.sdo.DataObject(DynWDO`account`ACCOUNT)",
dove ACCOUNT è il nome del nodo di dati.
Aggiornamento ai processori e gestori Diff automatici
I processori e i gestori Diff vengono generati automaticamente. Se i
processori e i gestori Diff per i componenti del client Faces sono stati
scritti in WebSphere Studio V5.1.x, si consiglia di eliminare il
codice e di utilizzare i gestori e i processori generati
automaticamente:
- Generare i nuovi gestori e processori Diff in ciascun oggetto dati client
nel progetto Web.
- Selezionare l'oggetto dati client con il tasto destro del mouse e
scegliere Configura.
- Nella scheda Avanzate, scegliere Rigenera
tutto.
- Rimuovere il codice scritto per richiamare i processori e i gestori Diff,
in quanto adesso verranno richiamati automaticamente. Un tipico esempio
dell'uso di questo codice, è l'evento Comando per il componente
Pulsante di comando,ad esempio:
String Diff = getClientData1().getDiffStr();
if (DiffProcessor.Synch(getRoot(), Diff) == true)
return "";
return "failure";
- Rimuovere i file corrispondenti ai vecchi gestori personalizzati e
processi creati dal progetto Web.
Conservazione dei gestori e processori Diff personalizzati scritti per
V5.1.x
Anche se non consigliato, se si decide di conservare i gestori e i
processori diff personalizzati della versione 5.1.x, sarà
necessario modificarli affinché possano funzionare nella versione
6.0, in quanto l'interfaccia DiffHandler e la classe DiffInfo sono
state modificate.
- L'interfaccia DiffHandler è stata modificata come segue:
- Il metodo handle adesso attiva una Exception oltre a una
DiffException.
- Il nuovo metodo find viene utilizzato dal framework per trovare
oggetti.
- Il nuovo metodo getId viene utilizzato per il debug e consente al
framework di stampare il valore dell'oggetto.
I metodi find e getId vengono utilizzati internamente dai DiffHandlers
generati. Per i DiffHandler personalizzati, è possibile implementare
metodi vuoti solo per compatibilità con l'interfaccia. Questi
metodi non verranno richiamati dal framework.
Adesso l'interfaccia 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);
}
- La classe DiffInfo è stata modificata come segue:
- Il metodo ArrayList getAncestors() è stato sostituito dal metodo
DiffInfo getParent(), che fornisce un modo più semplice di accedere alle
informazioni per ciascun oggetto nella struttura di elementi precedenti in
modo ricorsivo.
- I metodi getCurrent() e getOriginal() adesso restituiscono un oggetto
DataObject invece di un oggetto EObject. Non è obbligatorio
modificare il codice per utilizzare l'oggetto DataObject.
Tuttavia, l'interfaccia DataObject è molto più semplice e più
intuitiva da utilizzare rispetto a EObject. È possibile unire
facilmente un oggetto DataObject in un oggetto EObject per il codice
esistente.
- È stata aggiunta una nuova stringa di metodo getPropertyName() per
identificare il nome della proprietà alla quale viene applicato questo
oggetto È importante se, ad esempio, una classe data contiene due
proprietà dello stesso tipo. Precedentemente, nella classe DiffInfo,
il codice non sarebbe stato in grado di differenziare due proprietà.
La classe DiffInfo è stata modificata come segue:
public class DiffInfo
{
public char getCrud()
public DataObject getCurrent()
public String getEClassName()
public DataObject getOriginal()
public String getPropertyName()
public DiffInfo getParent()
}
- Nota:
- La classe DiffInfo non è più supportata per uso pubblico, in quanto i
processori e i gestori Diff non vengono più generati
automaticamente. Conservare i vecchi gestori solo come soluzione
temporanea e utilizzare i gestori automatici.
Modifiche ai componenti client Faces nella V6.0:
- Supporto per WebSphere Application Server V6.0.
- Supporto per SDO (Service Data Objects) su WebSphere Application Server
V6.0.
- Dati EGL supportati come dati client.
- Gestori e processori Diff generati automaticamente.
- Nuovi eventi per i seguenti componenti:
- TabbedPanel: onInitialPageShow
- Tree: onNodeExpand, onNodeCollapse, onExpand, onCollapse
- DataGrid: onPage, onSort, onFilter
Per i progetti Web Struts creati in WebSphere Studio V5.1.x,
sarà necessario applicare una piccola modifica al descrittore di
distribuzione del progetto Web affinché sia possibile eseguire il progetto
EAR in WebSphere Application Server V6.0. È anche possibile
convertire manualmente i progetti Web Struts 1.0.2 o Struts
1.1 Beta (2 o 3) in Struts 1.1.
Modifica del descrittore di distribuzione per i progetti Web Struts
esistenti
Nei progetti Struts creati in WebSphere Studio v5.x, il parametro
config (<param-name>config</param-name>) nel descrittore di
distribuzione del progetto Web, è impostato su
WEB-INF/struts-config.xml. WebSphere Application Server
V6.0 richiede che questo parametro contenga uno "/" iniziale. Se
si esegue un progetto Web Struts creato in WebSphere Studio
V5.1.x su WebSphere Application Server V6.0, è
possibile che si verifichi l'eccezione
java.net.MalformedURLException all'avvio del progetto
EAR.
- Nota:
- Rational Application Developer V6.0 aggiungerà il carattere "/"
quando viene creato un nuovo progetto Struts; tuttavia tale carattere
deve essere aggiunto manualmente durante la migrazione da WebSphere Studio
V5.1x.
Per correggere il descrittore di distribuzione di un progetto Web Struts
creato in WebSphere Studio v5.1.x per la versione 6.0,
procedere come segue:
- Aprire il progetto Web Struts in Esplora progetti.
- Fare doppio clic sul file Descrittore di distribuzione del
progetto Web in Esplora progetti. Viene aperto l'editor del
descrittore di distribuzione Web.
- Fare clic sulla scheda Origine per aprire la pagina
Origine.
- Modificare la riga
<param-value>WEB-INF/struts-config.xml</param-value>
(ubicata nei tag <servlet></servlet>)
in
<param-value>/WEB-INF/struts-config.xml</param-value>
.
- Salvare il descrittore di distribuzione Web
Adesso, al riavvio del progetto EAR, non dovrebbe verificarsi
l'eccezione java.net.MalformedURLException.
Conversione dei progetti Web Struts 1.1 Beta in Struts
1.1
In WebSphere Studio V5.1.x, la libreria di runtime Struts
passava da Struts 1.1 Beta (2 o 3) in V5.0.x a Struts
1.1 (finale). Se si dispone di progetti Web Struts 1.1
Beta (2 o 3) e si desidera convertirli in Struts 1.1 (finale), è
possibile effettuare l'operazione manualmente.
Nota: non è obbligatorio convertire i progetti Struts
1.1 Beta (2 o 3) in Struts 1.1.
Per convertire i progetti Struts 1.1 Beta (2 o 3) in Struts
1.1, procedere come segue:
- Caricare i progetti Struts 1.1 nello spazio di lavoro Rational
Application Developer V6.0.
- Creare un nuovo progetto Web Struts 1.1 Web chiamato, ad esempio,
Struts11. Questo progetto temporaneo deve essere creato per
poter accedere ai file di runtime Struts 1.1 necessari per la
conversione dei progetti reali. Al termine delle operazioni, è
possibile eliminare questo progetto.
- Per ciascun progetto Struts 1.1 Beta che si desidera convertire in
Struts 1.1, procedere come segue:
- Eliminare i seguenti file JAR dalla directory Content/WEB-INF/lib del
progetto Web:
- commons-*.jar.
- struts.jar.
- Copiare i seguenti file JAR dalla directory
Struts11/WebContent/WEB-INF/lib nella directory Web Content/WEB-INF/lib del
progetto Web:
- commons-*.jar.
- struts.jar.
- Eliminare i seguenti file TLD (Tag Library Descriptor) dalla directory
Content/WEB-INF del progetto Web: struts-*.tld.
- Copiare i seguenti file TLD dalla directory Struts11/WebContent/WEB-INF
nella directory Content/WEB-INF del progetto Web:
struts-*.tld.
Conversione progetti Web Struts 1.0.2 in Struts
1.1
In WebSphere Studio V5.1.x (e V5.0.x), quando
si aggiunge il supporto Struts a un progetto Web è possibile selezionare
l'opzione Struts 1.0.2. Se si dispone di progetti
Web Struts 1.0.2 e si desidera convertirli in Struts 1.1,
è possibile effettuare l'operazione manualmente.
Nota: non è obbligatorio convertire i progetti Struts
1.1 Beta (2 o 3) in Struts 1.1.
Per convertire il progetti Struts 1.0.2 in Struts 1.1,
procedere come segue:
- Caricare i progetti Struts 1.0.2 in uno spazio di lavoro
Rational Application Developer V6.0.
- Creare un nuovo progetto Web Struts 1.1, ad esempio
Struts11. Questo progetto temporaneo deve essere creato per
poter accedere ai file di runtime Struts 1.1 necessari per la
conversione dei progetti reali. Al termine delle operazioni, è
possibile eliminare questo progetto.
- Per ciascun progetto Struts 1.0.2 che si desidera convertire
in Struts 1.1, procedere come segue:
- Eliminare i file struts.jar dalla directory Content/WEB-INF/lib del
progetto Web.
- Copiare i seguenti file JAR dalla directory
Struts11/WebContent/WEB-INF/lib nella directory Web Content/WEB-INF/lib del
progetto Web:
- commons-*.jar.
- struts.jar.
- jarkarta-oro.jar.
- Eliminare i seguenti file TLD (Tag Library Descriptor) dalla directory
Content/WEB-INF del progetto Web: struts-*.tld.
- Copiare i seguenti file TLD dalla directory Struts11/WebContent/WEB-INF
nella directory Content/WEB-INF del progetto Web:
struts-*.tld.
In Rational Application Developer V6.0, sono state apportate diverse
modifiche agli strumenti di debug. Per utilizzare questi strumenti con
i progetti, dopo la migrazione, è necessario conoscere tali
modifiche. Potrebbe essere necessario modificare o ripristinare le
impostazioni.
Migrazione di spazi di lavoro e configurazioni di avvio
Quando uno spazio di lavoro V5.1.x di WebSphere Studio
Application Developer viene aperto in Rational Application Developer
V6.0, le configurazioni di avvio del debugger di seguito riportate
associate allo spazio di lavoro non vengono migrate automaticamente:
- Debug su server: Le configurazioni di avvio create in
precedenza mediante l'azione Debug su server non verranno migrate a
V6.0. Per avviare un'applicazione per il debug su un server
in V6.0, selezionare di nuovo l'applicazione e scegliere
Debug su server. Una nuova configurazione di avvio verrà
creata per l'applicazione.
- Server Attach: Le configurazioni di avvio di WebSphere
Application Server create in precedenza per una connessione al server non
verranno migrate a V6.0. La configurazione di avvio di debug di
WebSphere Application Server non esiste più. Per eseguire una
connessione al server per il debug in V6.0, utilizzare l'azione
Debug su server e creare una connessione al server WebSphere V5 per
5.x o una connessione al server WebSphere V6.0 per
6.0.
- Debugger SQLJ: La configurazione di avvio di debug SQLJ
non esiste più e le configurazioni di avvio SQLJ create in precedenza non
verranno migrate a V6.0. I programmi SQLJ di avvio per il debug
in V6.0 utilizzano la configurazione di avvio Java Application.
- Debugger procedure memorizzate: Le configurazioni di
avvio del debugger procedure memorizzate create in precedenza verranno migrate
a Rational Application Developer V6.0 e saranno disponibili per
l'uso nella finestra di dialogo delle configurazioni di avvio
Debug. Dopo la migrazione, se si utilizza l'azione
Debug nel menu a comparsa Vista Definizione dati,
verrà creata una nuova configurazione di avvio.
- Nota:
- Se si migra uno spazio di lavoro contenente una procedura memorizzata e si
genera nuovamente la procedura memorizzata per il debug, le configurazioni di
avvio migrate associate alla procedura memorizzata non funzionano.
- Debugger EGL: Dopo la migrazione di uno spazio di lavoro,
è necessario effettuare la seguente procedura per le configurazioni di
avvio del debugger EGL esistente:
- Modificare il JRE (Java runtime environment) installato affinché punti
al percorso corretto. Dopo la migrazione di uno spazio di lavoro, il
JRE installato punta al JRE della versione precedente di WebSphere Studio
Application Developer. Per modificare questa impostazione, puntare al
nuovo percorso JRE come segue:
- Selezionare Finestra -> Preferenze dal menu
del workbench.
- Nella finestra di dialogo Preferenze, espandere il nodo Java e
selezionare JRE installati.
- A destra, impostare il JRE installato affinché punti al JRE installato
con la versione corrente di questo prodotto. Il percorso del JRE è
la sottodirectory \eclipse\jre della directory di installazione di Rational
Application Developer V6.0.
- Nella configurazione di avvio, selezionare la scheda Origine
prima dell'avvio (se non viene eseguita questa operazione, verrà
visualizzato un errore "origine non trovata"). Se i percorsi di origine
sono stati aggiunti alla configurazione di avvio nello spazio di lavoro
V5.1.x, sarà necessario aggiungere di nuovo questi percorsi
manualmente alla configurazione di avvio migrata.
- Debugger linguaggio compilato: Dopo la migrazione di uno
spazio di lavoro, è necessario effettuare la seguente procedura per le
configurazioni di avvio del debugger del linguaggio compilato esistente:
- Se le variabili di ambiente sono state impostate nella scheda
Ambiente di sistema della configurazione di avvio Applicazione
compilata, è necessario aggiungere di nuovo manualmente le variabili
alla configurazione di avvio migrata.
- Se i percorsi di origine sono stati aggiunti alle configurazioni di avvio
Applicazione compilata o Connetti a un processo in
esecuzione, è necessario aggiungere di nuovo manualmente i percorsi
alla configurazione di avvio migrata.
Viste di debug
Le viste Memoria e Associazione memoria non esistono più. Tali
viste sono state sostituite dalle viste Memoria e Rendering della
memoria.
Debugger XSLT
Il debugger XSLT è stato modificato in V6.0, insieme a molte
viste ed azioni. Per ulteriori informazioni, fare riferimento alla
documentazione relativa al debugger XSLT nel centro informazioni.
Una delle modifiche più significative nel debugger XSLT è la
dipendenza dal JRE installato con Rational Application Developer
V6.0. Se si migra uno spazio di lavoro da WebSphere Studio
Application Developer V5.1.x, è necessario modificare il JRE
installato affinché indichi il percorso corretto, prima di avviare una
sessione di debug XSLT. Per questa operazione, è possibile eseguire
una delle seguenti azioni:
- Modificare il JRE per l'intero spazio di lavoro, puntando il JRE al
nuovo percorso JRE mediante la seguente procedura:
- Selezionare Finestra -> Preferenze dal menu
del workbench.
- Nella finestra Preferenze, espandere il nodo Java, quindi
selezionare JRE installati.
- A destra, impostare il JRE installato affinché punti al JRE installato
con la versione corrente di questo prodotto. Il percorso del JRE è
la sottodirectory \eclipse\jre della directory di installazione di Rational
Application Developer V6.0.
- Se si prevede di avviare la sessione di debug mediante la finestra di
dialogo delle configurazioni di avvio Debug, è possibile
modificare il JRE relativo alla configurazione di avvio puntando al nuovo
percorso JRE. Per eseguire questa operazione, aprire la configurazione
di avvio nella finestra di dialogo delle configurazioni di avvio
Debug. Selezionare la scheda JRE e specificare il
nuovo percorso JRE nel campo JRE alternativo.
Se in un progetto Web è stato creato un codice destinato a WebSphere
Application Server V5.1 che ha utilizzato record relazionali o elenchi
di record relazionali WDO (WebSphere Data Objects), quando le applicazioni
vengono destinate a WebSphere Application Server V6.0, vengono
utilizzati i record relazionali e gli elenchi di record relazionali SDO
(Service Data Objects). La migrazione da WDO a SDO si verifica
automaticamente quando si passa il server di destinazione
dell'applicazione da WebSphere Application Server V5.1 a WebSphere
Application Server V6.0.
Il server di destinazione può essere modificato in due modi:
- È possibile modificare il server di destinazione utilizzando la
finestra di dialogo delle proprietà del progetto. Fare clic con il
tasto destro del mouse sul progetto nella vista Esplora progetti e selezionare
Proprietà -> Server -> Runtime di
destinazione.
- Durante la migrazione J2EE mediante la procedura guidata Migrazione J2EE,
è possibile ristabilire la destinazione dell'applicazione per
utilizzare un altro server.
- Nota:
- È possibile eseguire la migrazione solo a un livello di specifica J2EE
superiore.
Gli argomenti della guida sulla modifica del server di destinazione e
sull'utilizzo della procedura guidata Migrazione J2EE sono disponibili
nella guida in linea relativa a Rational Application Developer.
Considerazioni sulla compatibilità
- Tutti i codici scritti nelle API (application programming interface)
pubbliche per i bean di accesso WDO sono supportati in V6.0 (nonostante
le classi di implementazione siano state modificate per avere come
destinazione il runtime SDO).
- Il nuovo codice generato per WebSphere Application Server V6.0 non
utilizza i bean di accesso WDO, ma genera un codice per le API SDO.
- Qualsiasi codice generato per un progetto destinato a V6.0 non
viene eseguito su un server V5.1, anche se migrato stabilendo di nuovo
la destinazione sul server.
- Il codice scritto per V5.1 può essere migrato in avanti e
all'indietro stabilendo come destinazione un server V5.1.
Conflitti durante la migrazione da WDO a SDO
Quando un progetto che utilizza WDO viene migrato a un progetto basato su
SDO, se si aggiungono dati SDO ad una pagina JSP esistente contenente dati
WDO, è possibile che si verifichino errori di conflitti. Questo
accade a causa dell'esistenza di bean di accesso WDO e API SDO
autonome. Ad esempio, potrebbe verificarsi un errore di compilazione
nel file di origine Java della JSP simile al seguente:
import com.ibm.websphere.sdo.mediator.exception.MediatorException genera un conflitto con un altro tipo
importato
Questi errori di conflitto possono essere corretti come segue:
- Rimuovere le istruzioni di importazione in conflitto dal file di origine
Java Java. Utilizzando l'esempio precedente, rimuovere la seguente
istruzione di importazione dal file di origine:
import com.ibm.websphere.wdo.mediator.exception.MediatorException;
- Modificare il file di origine Java che fa riferimento a questo tipo in
modo che utilizzi il nome classe completo. In base all'esempio
precedente, il tipo MediatorException deve essere modificato in
com.ibm.websphere.wdo.mediator.exception.MediatorException.
Ad esempio, il codice di origine scritto come
catch ( MediatorException e1 ) {
deve essere modificato in
catch ( com.ibm.websphere.wdo.mediator.exception.MediatorException e1 ) {
Modifiche a un progetto Web dopo il passaggio del server di
destinazione da V5.1 a V6.0 (da WDO a SDO)
Le modifiche di seguito riportate vengono eseguite automaticamente quando
il server di destinazione passa da V5.1 a V6.0:
- I file JAR (Java archive), wdo_web.jar e wdo_jdbc_access.jar
vengono rimossi dal progetto.
- I file JAR di seguito riportati vengono rimossi dal percorso classi del
progetto:
- emf-runtime.jar
- emf-event.jar
- wdo-interface.jar
- wdo.jar
- jdbcmediator.jar
- wdo.xmlmediator.jar
- I file sdo_web.jar e sdo_access_beans.jar vengono aggiunti
al progetto (i file JAR di runtime SDO vengono aggiunti automaticamente al
percorso classi di qualsiasi progetto V6.0).
- Tutti i file JAR JSTL (JavaServer Pages Standard Tag Library) 1.0
vengono rimossi dal progetto. (I file JAR JSTL 1.1/JSP
2.0 vengono aggiunti automaticamente al percorso classi del progetto
V6.0).
- Le istruzioni di importazione di seguito riportate vengono modificate in
file di origine Java:
- com.ibm.websphere.wdo.access.connections.ConnectionManager
viene modificato in
com.ibm.websphere.sdo.access.connections.ConnectionManager.
- com.ibm.websphere.wdo.mediator.rdb.ConnectionWrapper
viene modificato in
com.ibm.websphere.sdo.mediator.jdbc.ConnectionWrapper.
Modifiche a un progetto Web dopo il passaggio del server di
destinazione da V6.0 a V5.1 (da WDO a SDO)
Le modifiche di seguito riportate vengono eseguite automaticamente quando
il server di destinazione passa da V6.0 a V5.1:
- I file JAR sdo_web.jar e sdo_access_beans.jar vengono
rimossi dal progetto.
- I file JAR wdo_web.jar e wdo_jdbc_access.jar vengono
aggiunti al progetto.
- I file JAR di seguito riportati vengono aggiunti al percorso classi del
progetto:
- emf-runtime.jar
- emf-event.jar
- wdo-interface.jar
- wdo.jar
- jdbcmediator.jar
- wdo.xmlmediator.jar
- I file JAR JSTL 1.0 vengono aggiunti al progetto. (I file
JAR JSTL 1.1/JSP 2.0 vengono rimossi dal percorso classi del
progetto).
- Le istruzioni di importazione di seguito riportate vengono modificate in
file di origine Java:
- com.ibm.websphere.sdo.access.connections.ConnectionManager
diventa
com.ibm.websphere.wdo.access.connections.ConnectionManager.
- com.ibm.websphere.sdo.mediator.jdbc.ConnectionWrapper
diventa
com.ibm.websphere.wdo.mediator.rdb.ConnectionWrapper.
Modifiche a un progetto Web dopo il passaggio del livello J2EE
dell'applicazione da 1.3 a 1.4
Oltre alle modifiche che si verificano per eseguire la migrazione da WDO a
SDO, modificando la destinazione del server a WebSphere Application Server
V6.0, il passaggio del livello di specifica J2EE dell'applicazione
da 1.3 a 1.4 consente l'aggiornamento dei riferimenti
taglib (tag library) nelle JSP (JavaServer Pages) dall'utilizzo di WDO,
taglib JSTL 1.0, a taglib SDO, JSTL 1.1/jsp 2.0.
Nella tabella seguente vengono riportate le modifiche ai riferimenti taglib
JSP, quando si passa da J2EE 1.3 a J2EE 1.4.
Tabella 1. Riferimenti taglib JSP in J2EE 1.3 e J2EE 1.4.
J2EE 1.3 taglib (WDO)
| J2EE 1.4 taglib (SDO)
|
http://www.ibm.com/websphere/wdo/core
| http://www.ibm.com/websphere/sdo/core
|
http://java.sun.com/jstl/core
| http://java.sun.com/jsp/jstl/core
|
http://java.sun.com/jstl/fmt
| http://java.sun.com/jsp/jstl/fmt
|
http://java.sun.com/jstl/xml
| http://java.sun.com/jsp/jstl/xml
|
http://java.sun.com/jstl/sql
| http://java.sun.com/jsp/jstl/sql
|
Nuove parole riservate sono presenti in EGL (Enterprise Generation
Language), in Rational Application Developer.
Le nuove parole riservate sono di seguito riportate:
- as
- isa
- like
- matches
- money
- openUI
- ref
- self
- string
- this
I programmi EGL di WebSphere Studio V5.1.x importati e
generati in uno spazio di lavoro V6.0 che utilizzano queste parole come
nomi variabili o nomi di parte, presenteranno il seguente
messaggio:IWN.SYN.2002.e 39/2 Syntax error on
input "variableName". È possibile risolvere il problema
rinominando la variabile.
Le risorse di runtime di JavaServer Faces e del client Faces
originariamente fornite in Rational Application Developer V6.0 sono
state aggiornate per Rational Application Developer
V6.0.1. Se si desidera continuare lo sviluppo in progetti
Web creati con la versione precedente del prodotto, si consiglia di aggiornare
le risorse di runtime Faces e del client Client all'ultimo
livello.
In Rational Application Developer V6.0.1, gli aggiornamenti
alle risorse di runtime Faces e del client Faces vengono effettuati
automaticamente quando viene importato un progetto Web o quando viene aperto
uno spazio di lavoro che contiene risorse obsolete. Dopo aver importato
un progetto Web o aver aperto uno spazio di lavoro da Rational Application
Developer V6.0.x in Rational Application Developer
V6.0.1, verrà richiesto di aggiornare queste risorse di
runtime Faces all'ultimo livello.
Aggiornamento automatico delle risorse di runtime
Per aggiornare le risorse di runtime Faces e del client Faces
automaticamente per i progetti Web, procedere come segue:
- Importare un progetto Web (o uno spazio di lavoro) contenente dati Faces o
del client Faces da Rational Application Developer V6.0. Viene
aperta la finestra Migrazione progetto.
- Nota:
- Se la finestra Migrazione progetto non viene visualizzata, probabilmente
l'impostazione di generazione automatica è disabilitata. In
Esplora progetti, selezionare il progetto Web con il tasto destro del mouse e
scegliere Genera -> Progetto; il processo di
rigenerazione di un progetto apre la finestra Migrazione progetto.
- Se si dispone di altri progetti Web con contenuto Faces o del client Faces
nello spazio di lavoro, selezionare l'opzione Applica questa scelta
a tutti i progetti che devono essere aggiornati in modo che vengano
aggiornati tutti i progetti Web.
- Selezionare una delle seguenti opzioni:
- Sì per completare automaticamente
l'aggiornamento.
- Dopo per aggiornare in un secondo momento. Se si
seleziona Dopo, per aggiornare le risorse di runtime
automaticamente sarà necessario chiudere e riaprire il progetto Web o
riavviare il workbench prima di rigenerare il progetto Web. Se
l'operazione di generazione automatica è deselezionata, selezionare il
progetto Web con il tasto destro del mouse e selezionare Genera
progetto.
- Mai per lasciare le risorse di runtime al livello
inferiore. Se si seleziona Mai per non aggiornare
intenzionalmente le risorse di runtime, non verrà richiesto ancora di
aggiornarle. In seguito, qualora fosse necessario, le risorse di
runtime dovranno essere aggiornate manualmente.
Aggiornamento manuale delle risorse di runtime
Per aggiornare le risorse di runtime Faces e del client Faces
manualmente per i progetti Web, procedere come segue:
- Creare un nuovo progetto Web (o, se si utilizza EGL, creare un nuovo
progetto Web EGL) chiamato JSF601. Questo progetto verrà
utilizzato solo come origine per le ultime risorse di runtime; può
essere eliminato al termine dell'aggiornamento.
- In Esplora progetti, selezionare con il tasto destro del mouse il progetto
JSF601 e scegliere Proprietà dal menu.
- Scegliere Funzioni progetto Web e selezionare Aggiungi
componenti di base Faces e Aggiungi Faces Client Framework,
quindi scegliere OK.
- Se si utilizza EGL, creare un file di pagina JSF come
segue:
- Selezionare la cartella WebContent del nuovo progetto Web EGL.
- Selezionare Nuovo -> Altro -> File
JSP Faces.
I file eglintdebug.jar e
eglintdebugsupport.jar sono stati aggiunti al
progetto.
- Per ciascun progetto Faces esistente da aggiornare, procedere come
segue:
- In Esplora progetti, espandere un progetto esistente in modo da
visualizzare i file nella cartella WebContent/WEB-INF/lib/. Individuare
ed eliminare i seguenti file JAR in questa directory:
- eglintdebug.jar (solo EGL)
- eglintdebugsupport.jar (solo EGL)
- fda6.jar (solo EGL)
- fdaj6.jar (solo EGL)
- jsf-api.jar
- jsf-ibm.jar
- jsf-impl.jar
- odc-jsf.jar
- Per tutti i file JAR eliminati, copiare il file JAR dello stesso nome
dalla directory WebContent/WEB-INF/lib del progetto JSF601 e
incollarlo nel progetto originale nello stesso percorso. Alcune
configurazioni non richiedono che tutti questi file siano contenuti nel
progetto; non copiare i file JAR non presenti nel progetto
originale.
- Se si utilizza EGL, fare clic sul nome di ciascun progetto Web
EGL e scegliere Genera; quindi, se il progetto non viene
generato automaticamente, scegliere Progetto -> Genera
tutto.
- Eliminare il progetto Web JSF601.
Le risorse di runtime di JavaServer Faces e del client Faces
originariamente fornite in Rational Application Developer V6.0 sono
state aggiornate per Rational Application Developer
V6.0.1. Se si desidera continuare lo sviluppo in progetti
portlet creati con la versione precedente del prodotto, si consiglia di
aggiornare le risorse di runtime Faces e del client Client all'ultimo
livello.
In Rational Application Developer V6.0.1, gli aggiornamenti
alle risorse di runtime Faces e del client Faces vengono effettuati
automaticamente quando viene importato un progetto portlet o quando viene
aperto uno spazio di lavoro che contiene risorse obsolete. Dopo aver
importato un progetto portlet o aver aperto uno spazio di lavoro da Rational
Application Developer V6.0 in Rational Application Developer
V6.0.1, verrà richiesto di aggiornare queste risorse di
runtime Faces all'ultimo livello.
Aggiornamento automatico delle risorse di runtime
Per aggiornare le risorse di runtime Faces e del client Faces
automaticamente per i progetti portlet, procedere come segue:
- Importare un progetto portlet (o uno spazio di lavoro) contenente dati
Faces o del client Faces da Rational Application Developer V6.0.
Viene aperta la finestra Migrazione progetto.
- Nota:
- Se la finestra Migrazione progetto non viene visualizzata, probabilmente
l'impostazione di generazione automatica è disabilitata. In
Esplora progetti, selezionare il progetto portlet con il tasto destro del
mouse e scegliere Genera -> Progetto; il
processo di rigenerazione di un progetto apre la finestra Migrazione
progetto.
- Se si dispone di altri progetti portlet con contenuto Faces o del client
Faces nello spazio di lavoro, selezionare l'opzione Applica questa
scelta a tutti i progetti che devono essere aggiornati in modo che
vengano aggiornati tutti i progetti portlet.
- Selezionare una delle seguenti opzioni:
- Sì per completare automaticamente
l'aggiornamento.
- Dopo per aggiornare in un secondo momento. Se si
seleziona Dopo, per aggiornare le risorse di runtime
automaticamente sarà necessario chiudere e riaprire il progetto portlet o
riavviare il workbench prima di rigenerare il progetto portlet. Se
l'operazione di generazione automatica è deselezionata, selezionare il
progetto portlet con il tasto destro del mouse e selezionare Genera
progetto.
- Mai per lasciare le risorse di runtime al livello
inferiore. Se si seleziona Mai per non aggiornare
intenzionalmente le risorse di runtime, non verrà richiesto ancora di
aggiornarle. In seguito, qualora fosse necessario, le risorse di
runtime dovranno essere aggiornate manualmente.
- Per aggiornare le risorse di runtime Faces specifiche del portlet,
jsf-portlet.jar e jsf-wp.jar, sarà necessario seguire le
istruzioni per l'aggiornamento manuale riportate di seguito.
Aggiornamento manuale delle risorse di runtime
Per aggiornare le risorse di runtime Faces e del client Faces
manualmente per i progetti portlet, procedere come segue:
- Creare un nuovo progetto portlet chiamato JSFP601.
Questo progetto verrà utilizzato solo come origine per le ultime risorse di
runtime; può essere eliminato al termine
dell'aggiornamento.
- In Esplora progetti, selezionare con il tasto destro del mouse il progetto
JSFP601 e scegliere Proprietà dal menu.
- Scegliere Funzioni progetto Web e selezionare Aggiungi
Faces Client Framework per il progetto Portlet, quindi scegliere
OK.
- Per ciascun progetto portlet Faces esistente da aggiornare, procedere come
segue:
- In Esplora progetti, espandere un progetto esistente in modo da
visualizzare i file nella cartella WebContent/WEB-INF/lib/. Individuare
ed eliminare i seguenti file JAR in questa directory:
- jsf-api.jar
- jsf-ibm.jar
- jsf-impl.jar
- jsf-portlet.jar
- odc-jsf.jar
- Per tutti i file JAR eliminati, copiare il file JAR dello stesso nome
dalla directory WebContent/WEB-INF/lib del progetto JSFP601 e
incollarlo nel progetto originale nello stesso percorso. Alcune
configurazioni non richiedono che tutti questi file siano contenuti nel
progetto; non copiare i file JAR non presenti nel progetto
originale.
- Se il progetto portlet utilizza l'API portlet IBM o un componente di
collegamento Persona, copiare il file jsf-wp.jar nel progetto
originale.
- Se si copia il file odc-jsf.jar, copiare anche il file
odc-jsf-portlet.jar.
- Eliminare il progetto portlet JSFP601.
La procedura guidata Migrazione J2EE è stata aggiornata in Rational
Application Developer V6.0 per migrare i progetti J2EE nel livello di
specifica J2EE 1.4. La procedura guidata Migrazione J2EE
supporta la migrazione dalle specifiche J2EE 1.2 e 1.3 al
livello di specifica J2EE 1.4, per tutti i tipi di moduli J2EE.
Per i dettagli sulla migrazione delle risorse del livello di specifica J2EE
1.2 e 1.3 al livello di specifica J2EE 1.4, fare
riferimento a Migrazione dal livello di specifica J2EE 1.3 a 1.4 e Migrazione dal livello di specifica J2EE 1.2 a 1.4.
- Nota:
- Prima di utilizzare la procedura guidata Migrazione J2EE, attenersi alla
seguente procedura:
- Eseguire il backup dell'intero spazio di lavoro.
- Se si utilizza un repository condiviso, estrarre o bloccare tutti i
progetti corrispondenti.
È possibile accedere alla procedura guidata Migrazione J2EE come
segue:
- Nella vista Gerarchia J2EE della prospettiva J2EE, selezionare
con il tasto destro del mouse il progetto dell'applicazione enterprise
che si desidera migrare.
- Selezionare Migra -> Procedura guidata Migrazione
J2EE dal menu a comparsa.
- Prima di procedere con il processo di migrazione, seguire le istruzioni
della pagina di benvenuto della procedura guidata Migrazione J2EE.
Nota:
Per ulteriori informazioni sull'utilizzo della procedura guidata
Migrazione J2EE, fare riferimento alla guida in linea. Le modifiche
alla procedura guidata sono descritte in Modifiche nella procedura guidata Migrazione J2EE in Rational Application Developer V6.0.
Per i dettagli sulle modifiche alle risorse del livello di specifica J2EE
1.2 e 1.3 durante al migrazione al livello di specifica J2EE
1.4, fare riferimento a Migrazione dal livello di specifica J2EE 1.3 a 1.4 e Migrazione dal livello di specifica J2EE 1.2 a 1.4.
I servizi Web sicuri non vengono migrati dalla procedura guidata Migrazione
J2EE quando i servizi Web vengono migrati da J2EE 1.3 a J2EE
1.4. La migrazione dei servizi Web sicuri richiede una procedura
manuale.
Dopo la migrazione J2EE, i file di binding e di estensione sicuri devono
essere migrati manualmente a J2EE 1.4 come segue:
- Fare doppio client sul file webservices.xmlper aprire l'editor
Servizi Web.
- Selezionare la scheda Configurazioni binding per modificare il
file di binding.
- Aggiungere tutte le configurazioni di binding necessarie nelle nuove
sezioni Dettagli configurazione di binding del consumer della
richiesta e Dettagli configurazione del binding di generazione
della risposta.
- Selezionare la scheda Estensione per modificare il file di
estensione.
- Aggiungere tutte le configurazioni di estensione necessarie nelle nuove
sezioni Dettagli configurazione di binding del consumer della
richiesta e Dettagli configurazione del binding di generazione
della risposta.
- Salvare e chiudere l'editor.
I progetti J2EE possono essere migrati dal livello di specifica J2EE
1.3 a J2EE 1.4. Questa sezione illustra, per ciascun tipo
di progetto J2EE, le risorse migrate dal livello di specifica J2EE 1.3
a J2EE 1.4 mediante la procedura guidata Migrazione J2EE.
La procedura guidata Migrazione J2EE supporta la migrazione dei descrittori
di distribuzione bean enterprise dalla risorsa EJB del livello di specifica
J2EE 1.3 al livello di specifica J2EE 1.4. I bean di
sessione privi di stato e i bean basati sui messaggi vengono migrati a J2EE
1.4.
Migrazione di bean di sessione
La procedura guidata Migrazione J2EE consente di migrare i bean di sessione
privi di stato definiti come SEI (service endpoint interfaces) nel descrittore
webservices.xml di un progetto EJB dal livello di specifica J2EE
1.3 al livello di specifica J2EE 1.4, impostando nuove SEI
(service endpoint interfaces) nel bean di sessione privo di stato.
La specifica J2EE 1.4 richiede che una SEI sia definita in un bean
di sessione privo di stato, se il bean di sessione deve essere utilizzato come
endpoint dei servizi Web. Durante la migrazione di un file JAR EJB, in
tutti i bean di sessione del progetto EJB l'endpoint del servizio viene
impostato sul nome utilizzato nel descrittore webservices.xml del
progetto EJB. Di seguito viene riportato un esempio di come i metadati
di un progetto EJB appaiono prima e dopo la migrazione al livello di specifica
J2EE 1.4.
Progetto EJB in J2EE 1.3: descrittore
webservices.xml con bean di sessione privo di stato
utilizzato come service endpoint interface Web prima della migrazione
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE webservices PUBLIC "-//IBM Corporation, Inc.//DTD J2EE Web services 1.0//EN"
"http://www.ibm.com/webservices/dtd/j2ee_web_services_1_0.dtd">
<webservices id="WebServices_1084831328093">
<webservice-description id="WebServiceDescription_1084831328093">
<webservice-description-name>EchoEJBService</webservice-description-name>
<wsdl-file>META-INF/wsdl/EchoEJB.wsdl</wsdl-file>
<jaxrpc-mapping-file>META-INF/EchoEJB_mapping.xml</jaxrpc-mapping-file>
<port-component id="PortComponent_1084831328103">
<port-component-name>EchoEJB</port-component-name>
<wsdl-port id="WSDLPort_1084831328103">
<namespaceURI>http://test</namespaceURI>
<localpart>EchoEJB</localpart>
</wsdl-port>
<service-endpoint-interface>test.EchoEJB</service-endpoint-interface>
<service-impl-bean id="ServiceImplBean_1084831328103">
<ejb-link>EchoEJB</ejb-link>
</service-impl-bean>
</port-component>
</webservice-description>
</webservices>
I tag <service-endpoint-interface> e
<service-impl-bean> dell'esempio precedente definiscono
il bean di sessione privo di stato "EchoEJB" come endpoint di un servizio nel
descrittore dei servizi Web a livello di specifica J2EE 1.3 prima della
migrazione.
Progetto EJB in J2EE 1.4: descrittore di distribuzione
EJB per il bean di sessione privo di stato "EchoEJB" con service endpoint
interface creata dal processo di migrazione
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar>
<ejb-jar id="ejb-jar_ID" version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
<display-name>
EchoEJBProject</display-name>
<enterprise-beans>
<session id="EchoEJB">
<ejb-name>EchoEJB</ejb-name>
<home>test.EchoEJBHome</home>
<remote>test.EchoEJB</remote>
<service-endpoint>test.EchoEJB</service-endpoint>
<ejb-class>test.EchoEJBBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
Il tag <service-endpoint> dell'esempio precedente
definisce "EchoEJB" come endpoint di un servizio nel livello di specifica J2EE
1.4 dopo la migrazione.
Migrazione di bean basati sui messaggi
La procedura guidata Migrazione J2EE supporta la migrazione dei bean basati
sui messaggi di EJB 2.0 a EJB 2.1.
I bean basati sui messaggi sono stati introdotti in EJB 2.0 per
supportare l'elaborazione di messaggi asincroni da un JMS (Java Message
Service). La specifica EJB 2.1 espande la definizione di bean
basato sui messaggi in modo che possa supportare qualsiasi sistema di
messaggistica, non solo JMS.
- Nota:
- I bean basati sui messaggi migrati dal livello di specifica EJB 2.0 a
EJB 2.1 e distribuiti su to WebSphere Application Server versione 6
devono essere distribuiti su un adattatore di risorse JCA (Java Connector
Architecture) 1.5 invece che su una porta listener (come in WebSphere
Application Server versione 5). Affinché i bean basati sui messaggi
EJB 2.1 utilizzino un adattatore JCA, è necessario utilizzare
l'editor descrittore di distribuzione per modificare le impostazioni di
binding WebSphere. Vedere Configurazione di un bean basato sui messaggi EJB 2.1 affinché utilizzi un adattatore JCA.
Le risorse migrate dei bean basati sui messaggi EJB 2.0 sono:
- acknowledgeMode
- messageSelector
- destinationType
- subscriptionDurablity
Alcuni elementi di bean basati sui messaggi EJB 2.0 vengono
sostituiti con le proprietà activation-config. I nomi
delle proprietà ed i valori utilizzati nella proprietà
activation-config per descrivere il servizio di messaggistica
variano in base al tipo di servizio di messaggistica utilizzato.
Tuttavia, EJB 2.1 definisce un insieme di proprietà fisse per i bean
basati sui messaggi JMS.
Nell'esempio di seguito riportato, gli elementi di un bean di esempio
in EJB 2.0 vengono confrontati con il modo in cui gli elementi vengono
visualizzati in EJB 2.1
Un esempio di elementi di un bean basato sui messaggi in EJB
2.0:
<message-driven id="Mdb20">
<ejb-name>Mdb</ejb-name>
<ejb-class>ejbs.MdbBean</ejb-class>
<transaction-type>Bean</transaction-type>
<message-selector>mdbMessage</message-selector>
<acknowledge-mode>Auto-acknowledge</acknowledge-mode>
<message-driven-destination>
<destination-type>javax.jms.Topic</destination-type>
<subscription-durability>Durable</subscription-durability>
</message-driven-destination>
</message-driven>
Un esempio di elementi di un bean basato sui messaggi in EJB
2.1:
<message-driven id="Mdb21">
<ejb-name>Foo/ejb-name>
<ejb-class>ejbs.FooBean</ejb-class>
<messaging-type>javax.jms.MessageListener</messaging-type>
<transaction-type>Bean/transaction-type>
<message-destination-type>javax.jms.Topic</message-destination-type>
<activation-config>
<activation-config-property>
<activation-config-property-name>destinationType</activation-config-property-name>
<activation-config-property-value>javax.jms.Topic</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>subscriptionDurability</activation-config-property-name>
<activation-config-property-value>Durable</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>acknowledgeMode</activation-config-property-name>
<activation-config-property-value>AutoAcknowledge</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>messageSelector</activation-config-property-name>
<activation-config-property-value>fooSelector</activation-config-property-value>
</activation-config-property>
</activation-config>
</message-driven>
I bean basati sui messaggi migrati da EJB (Enterprise Java Bean) 2.0
al livello di specifica EJB 2.1 e sono distribuiti su WebSphere
Application Server versione 6, devono essere distribuiti su un adattatore di
risorse JCA (Java Connector Architecture) 1.5 invece che su una porta
listener.
Di seguito viene descritto come modificare il descrittore di distribuzione
dei bean basati sui messaggi EJB 2.1 affinché utilizzi un adattatore
JCA:
- Aprire il progetto EJB in Esplora progetti.
- Fare doppio clic sul file Descrittore di distribuzione del
progetto EJB in Esplora progetti. Viene aperto l'editor del
descrittore di distribuzione EJB.
- Scegliere la scheda Bean e aprire la pagina
Bean.
- Per ciascun bean basato sui messaggi EJB 2.1 nel progetto,
procedere come segue:
- Selezionare il bean basato sui messaggi EJB 2.1 nell'elenco di
bean situato a sinistra nella pagina Bean.
- Nell'intestazione Binding WebSphere, selezionare il
pulsante Adattatore JCA.
- Specificare le proprietà di distribuzione dei binding:
- Nome JNDI ActivationSpec.
Indicare il nome JNDI della specifica di attivazione J2C da utilizzare per
distribuire questo bean basato sui messaggi. Questo nome deve
corrispondere al nome di una specifica di attivazione J2C definita in
WebSphere Application Server.
- Alias autorizzazione ActivationSpec.
Il nome dell'alias di autenticazione J2C utilizzato per
l'autenticazione delle connessioni per l'adattatore di risorse
JCA. Gli alias di autenticazione J2C indicano l'ID utente e la
password da utilizzare per autenticare la creazione di una nuova connessione
all'adattatore di risorse JCA.
- Nome JNDI di destinazione.
Indicare il nome JNDI che il bean basato sui messaggi utilizzerà per
ricercare la destinazione JMS nello spazio nomi JNDI.
- Salvare le modifiche e chiudere l'editor del descrittore di
distribuzione.
Le risorse di un descrittore di distribuzione Web vengono migrate dalla
procedura guidata Migrazione J2EE quando un progetto Web del livello di
specifica J2EE 1.3 viene migrato al livello di specifica J2EE
1.4.
Vengono migrate le seguenti risorse di applicazione Web:
Vincoli di autenticazione
J2EE 1.4 include un oggetto Description che presenta due
attributi: lingua e valore. L'oggetto
Description non esisteva in J2EE 1.3; la descrizione era un
attributo del vincolo di autenticazione. Quindi, quando le risorse di
un descrittore di distribuzione Web vengono migrate a J2EE 1.4, il
valore dell'oggetto Description viene assunto
dall'attributo di descrizione del vincolo di autenticazione.
Vincoli di sicurezza
Allo stesso modo, in J2EE 1.3 la descrizione era un attributo di
Vincoli di sicurezza. In J2EE 1.4, esiste un nuovo oggetto
Description con gli attributi lingua e valore.
Quindi, il valore dell'oggetto Description viene assunto
dall'attributo di descrizione del vincolo di sicurezza.
Applicazione Web
L'attributo di descrizione dell'oggetto ContextParam nel livello
di specifica J2EE 1.3 è stato spostato in un oggetto Description in
ParamValue, in J2EE 1.4.
L'oggetto TagLib in J2EE 1.3 è stato spostato
nell'oggetto JSPConfig in J2EE 1.4. L'oggetto
JSPConfig apparteneva all'oggetto Web principale in 1.3.
La procedura guidata Migrazione J2EE consente di migrare le risorse di un
descrittore JCA (J2EE Connector architecture) 1.0 a JCA
1.5. Le risorse migrate sono correlate agli elementi
dell'oggetto ResourceAdaptor in quanto due nuovi oggetti,
OutboundResourceAdaptor e ConnectionDefinition, sono stati aggiunti
all'oggetto ResourceAdaptor nel livello di specifica J2EE 1.4 per
i progetti di connessione.
Di seguito viene descritta l'associazione degli elementi
migrati.
- Gli elementi di seguito riportati vengono spostati dall'oggetto
ResourceAdaptor all'oggetto OutboundResourceAdaptor:
- reauthenticationSupport
- transactionSupport
- Gli elementi di seguito riportati vengono spostati dall'oggetto
ResourceAdaptor all'oggetto ConnectionDefinition:
- managedConnectionFactoryClass
- connectionFactoryInterface
- connectionFactoryImplClass
- connectionInterface
- connectionImplClass
- L'oggetto outboundResourceAdaptor presenta un elenco di definizioni
ConnectionDefinition. L'elemento ConnectionDefinition viene
aggiunto all'elenco ConnectionDefinition gestito dall'oggetto
OutboundResourceAdaptor.
- L'oggetto OutboundResourceAdaptor è contenuto nell'oggetto
ResourceAdaptor.
- L'oggetto AuthenticationMechanism ha subito diverse modifiche in JCA
1.5, dove l'elemento customAuthMechType è sostituito da
authenticationMechanism e l'elemento authenticationType è sostituito
da authenticationMechanism
- L'attributo di descrizione nell'oggetto ResourceAdaptor è
sostituito con un oggetto Description, laddove la stringa degli attributi di
descrizione è impostata su un elemento di valore nell'oggetto
Description per i seguenti oggetti:
- SecurityPermission
- AuthenticationMechanism
- ConfigurationProperties
La specifica J2EE 1.4 ha aggiunto un supporto per i servizi Web
mediante la nuova API JAX-RPC 1.0.
L'API JAX-RPC supporta gli endpoint di servizio mediante:
- servlet con JAXR-RPC
- servlet con direct SOAP
- bean di sessione privi di stato
La specifica J2EE 1.4 supporta i servizi Web per la specifica J2EE
(JSR 109). JSR 109 definisce i requisiti di distribuzione per i servizi
Web ed utilizza il modello di programmazione JAX-RPC.
Le risorse dei servizi Web di seguito riportate vengono migrate utilizzando
la procedura guidata Migrazione J2EE:
- Descrittore di servizi Web
- Descrittore client di servizi Web
- Descrittore di associazione JAX-RPC
Migrazione di descrittori di distribuzione di servizi Web
I descrittori di distribuzione di servizi Web contenuti nei progetti J2EE
1.3 migrati al livello di specifica J2EE 1.4 verranno migrati da
JSR-109 V1.0 (per J2EE 1.3) a J2EE 1.4.
I descrittori di distribuzione dei servizi Web, come definiti da JSR-109
V1.0, sono costituiti da file webservices.xml,
webservicesclient.xml e da tutti i descrittori di distribuzione
dell'associazione JAX-RPC utilizzati come riferimento dai file
webservices.xml e webservicesclient.xml. Come con gli
altri descrittori di distribuzione J2EE, la migrazione modifica la struttura
delle informazioni contenute nei descrittori in modo che siano conformi alla
specifica J2EE 1.4. Una modifica strutturale particolare per i
descrittori di distribuzione dei servizi Web è la modifica della
rappresentazione dei nomi completi. In JSR-109 V1.0, i nomi
completi sono rappresentati utilizzando una sequenza di due elementi,
<namespaceURI> e <localpart>, contenenti
rispettivamente l'URI dello spazio nomi e la parte locale del
nome. I nomi completi in J2EE 1.4 sono basati sul tipo XMLSchema
QName, che utilizza gli spazi nomi XML.
Di seguito sono riportati ulteriori dettagli sulla migrazione di ciascun
descrittore di distribuzione dei servizi Web.
- Descrittore dei servizi Web (webservices.xml)
Il descrittore di distribuzione webservices.xml è presente nei
progetti Web e nei progetti EJB contenenti servizi Web J2EE. Gli
elementi <wsdl-port> e <soap-header>
contengono entrambi nomi completi ed il loro contenuto viene migrato nel
formato J2EE 1.4.
Ad esempio, se <wsdl-port> è rappresentato come segue
prima della migrazione
<wsdl-port>
<namespaceURI>http://addressbook.webservice</namespaceURI>
<localpart>AddressBook</localpart>
</wsdl-port>
dopo la migrazione <wsdl-port> apparirà nel seguente
modo:
<wsdl-port xmlns:pfx="http://addressbook.webservice">pfx:AddressBook</wsdl-port>
Il prefisso "pfx" viene utilizzato come prefisso dello spazio nomi per
tutti i nomi completi migrati.
- Descrittore client di servizi Web
(webservicesclient.xml)
Il descrittore di distribuzione webservicesclient.xml è presente
nei progetti Web J2EE 1.3, nei progetti EJB e nei progetti client di
applicazioni contenenti client dei servizi Web J2EE. Durante la
migrazione da J2EE 1.3 a 1.4, il contenuto di
webservicesclient.xml viene migrato e spostato nel descrittore di
distribuzione relativo al progetto. Il processo viene di seguito
riportato:
- Per i progetti Web, tutti gli elementi <service-ref>
presenti in webserivcesclient.xml vengono spostati nell'elemento
<web-app> di web.xml.
- Per i progetti client di applicazioni, tutti gli elementi
<service-ref> presenti in webservicesclient.xml
vengono spostati nell'elemento <application-client> di
application-client.xml.
- Per i progetti EJB, tutti gli elementi <service-ref>
all'interno di un <component-scoped-refs> di
webserviceclient.xml vengono spostati nell'elemento
<enterprise-bean> corrispondente in
ejb-jar.xml.
- Webservicesclient.xml viene eliminato.
Gli elementi <service-qname> e
<soap-header> contengono entrambi nomi completi ed il loro
contenuto viene migrato nel formato J2EE 1.4. Ad esempio, se
<service-qname> è rappresentato come segue prima della
migrazione
<service-qname>
<namespaceURI>http://addressbook.webservice</namespaceURI>
<localpart>AddressBookService</localpart>
</service-qname>
dopo la migrazione <service-qname> apparirà nel
seguente modo:
<service-qname xmlns:pfx="http://addressbook.webservice">pfx:AddressBookService</service-qname>
Il prefisso "pfx" viene utilizzato come prefisso dello spazio nomi per
tutti i nomi completi migrati.
- Descrittore dell'associazione JAX-RPC
I descrittori di distribuzione webservices.xml e
webservicesclient.xml possono fare riferimento a uno o più
descrittori di distribuzione dell'associazione JAX-RPC.
Nel file webservices.xml, questi riferimenti sono contenuti
nell'elemento <jaxrpc-mapping-file> presente in ciascun
elemento <webservice-description>. Nel file
webservicesclient.xml, questi riferimenti sono contenuti
nell'elemento <jaxrpc-mapping-file> presente in ciascun
elemento <service-ref>.
Durante la migrazione da J2EE 1.3 a 1.4, tutti i descrittori
di distribuzione dell'associazione JAX-RPC a cui si fa riferimento in
webservices.xml e webservicesclient.xml vengono migrati.
Il processo di migrazione include la migrazione di tutti i nomi completi nel
formato J2EE 1.4 (per esempi di nomi completi dopo la migrazione, fare
riferimento alle sezioni sopra riportate relative a webservices.xmle
webservicesclient.xml).
I moduli J2EE possono essere migrati dal livello di specifica J2EE
1.2 a J2EE 1.4. Questa sezione illustra le risorse
migrate per i progetti J2EE dal livello di specifica J2EE 1.2 a J2EE
1.4 mediante la procedura guidata Migrazione J2EE.
Per i dettagli sull'utilizzo della procedura guidata Migrazione J2EE,
fare riferimento a Capitolo 4, Migrazione di progetti J2EE.
La migrazione di un progetto EJB dal livello di specifica EJB 1.1 a
EJB 2.1 viene descritta in questa sezione.
La migrazione di un progetto EJB da EJB 1.1 a EJB 2.1
coinvolge la migrazione dei bean entity CMP (container-managed
persistence):
Non sono state apportate modifiche ai bean entity tra il livello di
specifica J2EE 1.3 e J2EE 1.4. La migrazione dei bean
entity CMP dal livello di specifica EJB 1.1 a EJB 2.1 viene
eseguita nello stesso modo della migrazione di un bean entity CMP da EJB
1.1 a EJB 2.0. La migrazione dei bean entity gestiti dal
contenitore dal livello di specifica EJB 1.1 a EJB 2.x richiede
la seguente procedura:
- Conversione del progetto EJB da EJB 1.1 a
EJB 2.x.
- Migrazione del codice EJB da EJB 1.1 a EJB
2.x.
- Migrazione di tutti i riferimenti EJB
1.1 definiti dall'utente nei riferimenti locali in EJB
2.x.
Un progetto EJB 1.1 può essere convertito in un progetto EJB
2.x utilizzando la procedura guidata Migrazione J2EE.
- Nella vista Gerarchia J2EE, selezionare il progetto 1.1 con il
tasto destro del mouse, quindi scegliere Migra ->
Procedura guidata Migrazione J2EE.
In alternativa, se si desidera preservare il progetto EJB 1.1
originale, è possibile creare un nuovo progetto 2.x e importarvi il
file JAR del progetto esistente (File -> Importa
-> JAR EJB).
Anche se questo è un progetto EJB 2.x, i bean entity CMP
(container-managed persistence) EJB 1.1 esistenti (o importati) restano
invariati. Pertanto, i bean entity CMP non vengono convertiti in EJB
2.
La procedura guidata Migrazione J2EE consente di migrare i bean enterprise
all'interno di un progetto EJB 2.x da 1.1 a
2.x. Se si desidera migrare i bean entity CMP 1.1 a
2.x, sarà necessario migrare tutti i bean contenuti nel progetto
2.x. Tuttavia, è possibile scegliere di aggiungere viste
client locali ai bean 2.x migrati.
- La procedura guidata consente di conservare l'eredità EJB
1.1 esistente nel progetto EJB 2.x.
- La procedura guida consente di migrare le relazioni EJB 1.1
(esclusive) nelle relazioni EJB 2.x (standard), oltre ad altri
vantaggi.
- Nota:
- Se sono presenti associazioni, verranno create associazioni EJB 2.x,
ma le relative associazioni di ruoli non saranno più valide.
Eseguendo il processo di convalida, si verificheranno degli errori. Per
risolvere gli errori, aprire l'editor di associazione e salvare
l'associazione. Le associazioni di ruoli saranno rimosse. A
questo punto, eseguire nuovamente la convalida e riassociare i ruoli.
Per i progetti convertiti da EJB 1.1 a EJB 2.x, è
necessario attenersi alla seguente procedura per migrare il codice esistente
da EJB 1.1 a EJB 2.x.
- Nota:
- I bean EJB 2.x sono supportati solo in un progetto EJB 2.x
(tuttavia, i progetti 2.x supportano anche i bean 1.1).
- Per qualsiasi bean CMP 1.1, sostituire ogni campo CMP con metodi
getXXX e setXXX astratti. Anche la classe bean
deve essere astratta.
- Per CMP, creare un metodo astratto getXXX e setXXX
per la chiave primaria.
- Per il metodo finder CMP 1.1, creare un metodo EJBQL
(EJB Query Language) per ogni metodo finder.
- Nota:
- EJB Query Language ha le seguenti limitazioni in Rational Application
Developer V6.0:
- Le query di EJB Query Language che comprendono EJB con chiavi composte di
relazioni ad altri EJB verranno visualizzate come non valide e causeranno
errori in fase di impiego.
- Il supporto IBM EJB Query Language estende la specifica EJB 2.x in
vari modi, tra cui la riduzione di alcune limitazioni, l'aggiunta di un
supporto per più funzioni DB2 e così via. Se la portabilità
attraverso vari database di fornitori o strumenti di distribuzione EJB
costituisce un problema, allora l'attenzione deve essere rivolta a
scrivere tutte le query EJB Query Language rigorosamente in base alle
istruzioni descritte nel capitolo 11 della specifica EJB 2.x.
- Per qualsiasi finder CMP 1.1, restituire
java.util.Collection anziché
java.util.Enumeration.
- Per i bean CMP 1.1, modificare tutte le ricorrenze della stringa
this.field = value con setField(value) in
ejbCreate() ed in qualsiasi altro punto del codice.
- Aggiornare la gestione delle eccezioni (funzione rollback) per le
eccezioni non appartenenti all'applicazione:
- Attivare javax.ejb.EJBException anziché
java.rmi.RemoteException per riportare le eccezioni
non appartenenti all'applicazione.
- In EJB 2.x e 1.1, tutte le eccezioni non appartenenti
all'applicazione attivate dall'istanza generano il rollback della
transazione in cui è eseguita l'istanza e la eliminano.
- Aggiornare la gestione delle eccezioni (funzione rollback) per le
eccezioni dell'applicazione:
- In EJB 2.x e 1.1, un'eccezione di applicazione non
provoca il rollback automatico di una transazione da parte del
contenitore.
- In EJB 1.1, il contenitore esegue il rollback solo se
l'istanza è stata richiamata utilizzando il metodo
setRollbackOnly() sull'oggetto EJBContext.
- Aggiornare le impostazioni CMP dei valori predefiniti specifici
dell'applicazione in modo che siano all'interno di
ejbCreate (non utilizzare variabili globali, poiché i
contenitori EJB 1.1 impostano tutti i campi su valori predefiniti
generici prima di richiamare ejbCreate che sovrascriverà tutte
le precedenti impostazioni predefinite specifiche
dell'applicazione).
Durante la creazione delle relazioni EJB 1.1, sono stati creati
riferimenti EJB alla vista Client remoto. Durante la migrazione dei
progetti EJB 1.1 attraverso la procedura guidata Migrazione J2EE, tali
riferimenti EJB remoti per le relazioni EJB 1.1 vengono rimossi e
sostituiti con riferimenti EJB locali. I riferimenti locali per i
riferimenti EJB definiti dall'utente devono essere ricreati
manualmente.
- Nota:
- In EJB 2.x, le relazioni EJB possono essere create solo se la vista
Client locale è stata definita per i bean e se i riferimenti EJB locali
sono stati creati per le relazioni EJB 2.x.
Per i riferimenti EJB definiti dall'utente, la migrazione
non viene eseguita attraverso la procedura guidata Migrazione
J2EE. Tuttavia, per impostare i riferimenti locali, procedere come
segue:
- Eliminare i riferimenti remoti EJB nella pagina Riferimenti
dell'editori del descrittore di distribuzione.
- Aggiungere un riferimento EJB locale nella pagina Riferimenti
dell'editor del descrittore di distribuzione.
Durante la migrazione della struttura del progetto attraverso la procedura
guidata Migrazione J2EE, gli elementi del metodo (che comprendono identità
di protezione, transazione dei contenitori, autorizzazioni del metodo,
tentativo di accesso e livelli di isolamento) dello stesso tipo per tutti i
bean, vengono uniti per raggrupparli logicamente.
Di seguito è riportato un esempio degli elementi del metodo prima e dopo
la migrazione della struttura del progetto.
L'esempio seguente mostra l'autorizzazione del metodo nella
pagina di origine dell'editor del descrittore di distribuzione prima
della migrazione della struttura del progetto.
<method-permission>
<role-name>rol1</role-name>
<role-name>rol2</role-name>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getEJBMetaData</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getHomeHandle</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-namae>remove</method-name>
<method-params>
<method-param>java.lang.Object</method-param>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>javax.ejb.Handle</method-param>
</method-params>
</method>
</method-permission>
<method-permission>
<role-name>rol1</role-name>
<role-name>rol2</role-name>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Remote</method-intf>
<method-name>isIdentical</method-name>
<method-params>
<method-param>javax.ejb.EJBObject</method-param>
</method-params>
</method>
</method-permission>
L'esempio seguente mostra l'autorizzazione del metodo nella
pagina di origine dell'editor del descrittore di distribuzione dopo la
migrazione della struttura del progetto.
<method-permission>
<role-name>rol1</role-name>
<role-name>rol2</role-name>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getEJBMetaData</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getHomeHandle</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>>java.lang.Object</method-param>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>javax.ejb.Handle</method-param>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Remote</method-intf>
<method-name>isIdentical</method-name>
<method-params>
<method-param>javax.ejb.EJBObject</method-param>
</method-params>
</method>
</method-permission>
- Nota:
- Se nella procedura guidata Migrazione J2EE, oltre alla migrazione della
struttura del progetto è stata selezionata anche la migrazione dei bean da
CMP 1.x a CMP 2.x, i tentativi di accesso e i livelli di
isolamento vengono rimossi, mentre i rimanenti elementi verranno uniti durante
la migrazione. I tentativi di accesso e il livello di isolamento
vengono rimossi perché non vengono più considerati validi a causa delle
modifiche apportate al modello di estensioni. Con il nuovo modello,
sono disponibili i tentativi di accesso e il livello di isolamento definito
nei tentativi di accesso, i tentativi di accesso di livello bean e di livello
metodo. È preferibile utilizzare i tentativi di accesso di livello
bean piuttosto che di livello metodo.
Le risorse di un descrittore di distribuzione Web vengono migrate dalla
procedura guidata Migrazione J2EE quando un progetto Web J2EE 1.2 viene
migrato al livello di specifica J2EE 1.4.
Vengono migrate le seguenti risorse di applicazione Web:
Vincoli di autenticazione
J2EE 1.4 include un oggetto Description che presenta due
attributi: lingua e valore. L'oggetto
Description non esisteva in J2EE 1.2; la descrizione era un
attributo del vincolo di autenticazione. Quindi, quando le risorse di
un descrittore di distribuzione Web vengono migrate a J2EE 1.4, il
valore dell'oggetto Description viene assunto
dall'attributo di descrizione del vincolo di autenticazione.
Vincoli di sicurezza
Allo stesso modo, in J2EE 1.2 la descrizione era un attributo di
Vincoli di sicurezza. In J2EE 1.4, esiste un nuovo oggetto
Description con gli attributi lingua e valore.
Quindi, il valore dell'oggetto Description viene assunto
dall'attributo di descrizione del vincolo di sicurezza.
Applicazione Web
L'attributo di descrizione dell'oggetto ContextParam nel livello
di specifica J2EE 1.2 è stato spostato in un oggetto Description in
ParamValue, in J2EE 1.4.
L'oggetto TagLib in J2EE 1.2 è stato spostato
nell'oggetto JSPConfig in J2EE 1.4. L'oggetto
JSPConfig apparteneva all'oggetto Web principale in 1.2.
Alla procedura guidata Migrazione J2EE in Rational Application Developer
V6.0 sono state apportate modifiche comuni alla migrazione di tutti i
livelli di specifica J2EE.
Migrazione facoltativa della struttura del progetto
In WebSphere Studio da V5.1.x a V5.1.2, la
migrazione della struttura del progetto viene eseguita contemporaneamente alla
migrazione del livello di specifica J2EE. La migrazione della struttura
del progetto non è facoltativa quando si migrano i livelli di specifica
J2EE.
Nella procedura guidata Migrazione J2EE in Rational Application Developer
V6.0, l'opzione Migra la struttura del progetto è
un'opzione facoltativa diversa dall'opzione Migra il livello di
specifica J2EE del progetto. La migrazione del livello di
specifica J2EE e la migrazione della struttura del progetto possono essere
eseguite indipendentemente.
Server di destinazione obbligatorio
In Rational Application Developer V6.0, i progetti J2EE nuovi ed
esistenti migrati a un livello di specifica J2EE superiore richiedono un
server di destinazione impostato nel progetto. Il server di
destinazione è il meccanismo predefinito per cui il percorso classi viene
impostato in un progetto J2EE in V6.0. Per informazioni
sull'impostazione di un server di destinazione e sull'utilizzo della
procedura guidata Migrazione J2EE, fare riferimento alla guida in
linea.
I progetti di Portal Toolkit V5.0.2.2 verranno migrati
automaticamente agli strumenti del portale Rational Application Developer
V6.0 migrando lo spazio di lavoro di Toolkit o caricando il progetto da
un sistema SCM (source code management) o importando il progetto utilizzando
la funzione Project Interchange. Se si desidera eseguire la migrazione
dalle versioni precedenti di Portal Toolkit, è necessario esportare i
progetti portlet nei file WAR e importare i file WAR negli strumenti Portal in
Rational Application Developer V6.0.
Prima di migrare le applicazioni del portale, è necessario installare la
funzione relativa agli strumenti del portale di Rational Application Developer
V6.0. Fare riferimento alla guida
all'installazione.
- Nota:
- La compatibilità con le versioni precedenti dei progetti portlet non è
supportata.
La migrazione automatica è supportata solo per i progetti creati in
Portal Toolkit V5.0.2.2 con WebSphere Studio
V5.1.2. Per i dettagli sulla migrazione, fare riferimento
a Capitolo 1, Migrazione da WebSphere Studio V5.1, 5.1.1 o 5.1.2.
Se il progetto portlet è associato ad un progetto applicazione
enterprise, sarà necessario impostare il server di destinazione appropriato
sul progetto EAR. È possibile impostare il server di destinazione
nella pagina Proprietà server (Proprietà ->
Server).
Durante la migrazione dei progetti Portal Toolkit
V5.0.2.2, vengono effettuate altre modifiche:
- Se non è impostato alcun server di destinazione per il progetto il
server di destinazione verrà impostato su WebSphere Portal V5.0
- Il percorso di generazione portlet viene corretto
- Viene aggiunta una natura del progetto portlet.
Se si desidera eseguire la migrazione dalle versioni precedenti di Portal
Toolkit, è necessario migrare manualmente i progetti portlet agli strumenti
Portal in Rational Application Developer V6.0, come segue:
- Esportare il progetto esistente in un file WAR: Nella versione
precedente di Portal Toolkit, esportare ciascun progetto in un file WAR con i
file di origine.
- Selezionare il progetto con il tasto destro del mouse e scegliere
Esporta.
- Selezionare File WAR e Esporta file di origine,
quindi fare clic su Fine.
- Importare il file WAR portlet:
- Negli strumenti Portal relativi a Rational Application Developer
V6.0, creare un nuovo progetto portlet vuoto.
- Selezionare File -> Nuovo ->
Progetto -> Portal -> Progetto Portlet
o Progetto Portlet (JSR 168).
- Deselezionare l'opzione Crea portlet.
- Scegliere Mostra avanzate.
- Se si sta importando un portlet WebSphere Portal 4.2, selezionare
2.2 come versione servlet.
- Selezionare WebSphere Portal v5.0 come server di
destinazione e scegliere Fine.
- Importare il file WAR nel nuovo progetto portlet vuoto.
- Selezionare Importa.
- Selezionare File WAR e specificare il file WAR esportato in
precedenza (Esportazione di un progetto in un file WAR nella versione
precedente).
- Selezionare il nuovo progetto portlet vuoto.
- Selezionare Sovrascrivi risorse esistenti senza avviso.
- Non selezionare Elimina progetto se
sovrascritto.
- Eliminare il file TLD:
Si consiglia di eliminare il file TLD portlet dal progetto, se
esistente. Altrimenti, verrà visualizzato un messaggio di avviso
alla successiva generazione del progetto. Se il file non viene
eliminato, ciò potrebbe provocare un problema quando il progetto portlet
viene distribuito su WebSphere Portal e il file TLD del portlet è diverso
dal file presente sul server.
- Se si sta migrando un portlet WebSphere Portal 4.2, sarà
necessario migrare il progetto portlet migrato a WebSphere Portal
5.x.
Per informazioni sulla migrazione dei portlet WebSphere Portal da
V4.2 a V5.x, fare riferimento a Migrazione dei portlet WebSphere Portal da V4.2 a V5.x.
Per informazioni sulla migrazione delle risorse Faces in un progetto
portlet, fare riferimento a Aggiornamento delle risorse di runtime Faces in un progetto portlet.
Rational Application Developer V6.0 non supporta lo sviluppo di
portlet WebSphere Portal V4.2. È necessario migrare i
progetti portlet di WebSphere Portal V4.2 a V5.x.
Molti portlet scritti per WebSphere Portal V4.2 vengono eseguiti in
WebSphere Portal V5.x senza alcuna modifica. Alcune API del
portlet 4.2.x sono ora contrassegnate come obsolete, ma sono
ancora disponibili su WebSphere Portal V5.x.
- Nota:
- I progetti applicazione portlet migrati non sono compatibili con le versioni
precedenti.
Per migrare le applicazioni portlet relative a WebSphere Portal da
V4.2 a V5.x, procedere come segue:
- Migrare i progetti portlet da Portal V4.2 a Portal
V5.x:
- Selezionare con il tasto destro del mouse il progetto applicazione portlet
da migrare.
- Selezionare Proprietà -> API Portlet per
aprire la pagina API Portlet.
- Selezionare WebSphere Portal Versione 5.x
dall'elenco a discesa di livello API Portlet.
- Fare clic su OK, le modifiche di seguito riportate verranno
effettuate automaticamente:
- Il file TLD (tag library descriptor) relativo all'API portlet viene
rimosso, se esiste.
- Il livello Web viene modificato da 2.2 a 2.3.
- Le voci del percorso classi specifiche del portlet vengono rimosse, quando
il contenitore JRE WebSphere Portal e il contenitore di destinazione di
runtime WebSphere Portal aggiungono le voci in modo dinamico.
- Se il progetto portlet è associato a un progetto applicazione
enterprise, si consiglia di migrare il livello J2EE del progetto EAR a J2EE
1.3. Le applicazioni portlet progettate per WebSphere Portal
V5.x devono essere conformi alle specifiche J2EE livello
1.3.
- Nota:
- Prima di migrare il progetto applicazione enterprise a J2EE 1.3,
leggere Capitolo 4, Migrazione di progetti J2EE. Per informazioni sull'utilizzo della procedura
guidata Migrazione J2EE, fare riferimento alla guida in linea.
- Se il progetto portlet migrato è associato solo al progetto
applicazione enterprise, procedere come segue:
- Chiudere tutti gli editor del workbench.
- Fare clic con il tasto destro del mouse sul progetto applicazione
enterprise con cui è associato il progetto portlet migrato.
- Selezionare Migra -> Procedura guidata Migrazione
J2EE e fare clic su Avanti.
- Selezionare J2EE versione 1.3 e WebSphere
Portal come server di destinazione.
- Scegliere Fine.
- Se altri progetti portlet sono associati al progetto applicazione
enterprise, è necessario rimuovere il progetto portlet migrato e
aggiungerlo ad un altro progetto applicazione enterprise.
- Rimuovere il modulo del progetto portlet migrato dal progetto applicazione
enterprise.
- Espandere il progetto applicazione enterprise e selezionare il descrittore
di distribuzione.
- Selezionare Apri con -> Editor del descrittore di
distribuzione.
- Selezionare la scheda Modulo. Nella pagina Modulo
dell'editor, selezionare il file WAR del progetto portlet migrato.
- Fare clic su Rimuovi.
- Selezionare File -> Salva per salvare le
modifiche.
- Creare un nuovo progetto applicazione enterprise e aggiungervi il progetto
portlet.
- Selezionare File -> Nuovo ->
Progetto.
- Selezionare la casella di controllo Mostra tutte le procedure
guidate.
- Espandere J2EE e selezionare Progetto applicazione
Enterprise.
- Inserire i dati nel campo Nome del progetto, selezionare
J2EE versione 1.3 e WebSphere Portal come server
di destinazione, quindi fare clic su Avanti.
- Nella pagina Progetti modulo EAR, selezionare il progetto
portlet migrato e fare clic su Fine.
Il progetto portlet viene ora migrato a WebSphere Portal
V5.x.
Le risorse di runtime JavaServer Faces runtime originariamente fornite con
WebSphere Studio Application Developer V5.1.2 sono state
aggiornate per Rational Application Developer V6.0.1. Se
si desidera continuare lo sviluppo in progetti portlet creati con Portal
Toolkit 5.0.2.2 per la versione precedente del prodotto,
si consiglia di aggiornare le risorse di runtime Faces Client all'ultimo
livello.
In Rational Application Developer V6.0.1, gli aggiornamenti
alle risorse di runtime Faces vengono effettuati automaticamente quando viene
importato un progetto portlet o quando viene aperto uno spazio di lavoro che
contiene risorse obsolete. Dopo aver importato un progetto portlet
creato con Portal Toolkit 5.0.2.2 per WebSphere Studio
Application Developer V5.1.x in Rational Application Developer
V6.0.1, verrà richiesto di aggiornare le risorse di runtime
Faces all'ultimo livello.
Aggiornamento automatico delle risorse di runtime
Per aggiornare le risorse di runtime Faces automaticamente per i
progetti portlet, procedere come segue:
- Importare un progetto portlet contenente dati Faces da WebSphere Studio
Application Developer V5.1.x. Viene aperta la finestra
Migrazione progetto.
- Nota:
- Se la finestra Migrazione progetto non viene visualizzata, probabilmente
l'impostazione di generazione automatica è disabilitata. In
Esplora progetti, selezionare il progetto portlet con il tasto destro del
mouse e scegliere Genera -> Progetto; il
processo di rigenerazione di un progetto apre la finestra Migrazione
progetto.
- Se si dispone di altri progetti portlet con contenuto Faces nello spazio
di lavoro, selezionare l'opzione Applica questa scelta a tutti i
progetti che devono essere aggiornati in modo che vengano aggiornati
tutti i progetti portlet.
- Selezionare una delle seguenti opzioni:
- Sì per completare automaticamente
l'aggiornamento.
- Dopo per aggiornare in un secondo momento. Se si
seleziona Dopo, per aggiornare le risorse di runtime
automaticamente sarà necessario chiudere e riaprire il progetto portlet o
riavviare il workbench prima di rigenerare il progetto portlet. Se
l'operazione di generazione automatica è deselezionata, selezionare il
progetto portlet con il tasto destro del mouse e selezionare Genera
progetto.
- Mai per lasciare le risorse di runtime al livello
inferiore. Se si seleziona Mai per non aggiornare
intenzionalmente le risorse di runtime, non verrà richiesto ancora di
aggiornarle. In seguito, qualora fosse necessario, le risorse di
runtime dovranno essere aggiornate manualmente.
- Per aggiornare le risorse di runtime Faces specifiche del portlet,
jsf-portlet.jar e jsf-wp.jar, sarà necessario seguire le
istruzioni per l'aggiornamento manuale riportate di seguito.
- Nota:
- Se sono state create JSP Faces contenenti componenti del client Faces,
sarà necessario aggiornare separatamente le risorse di runtime dei
componenti del client Faces all'ultimo livello. Consultare la
sezione Aggiornamento delle risorse di runtime Faces Client in un progetto Web.
Aggiornamento manuale delle risorse di runtime
Per aggiornare le risorse di runtime Faces manualmente per i
progetti portlet, procedere come segue:
- Importare il progetto portlet esistente con contenuto Faces nello spazio
di lavoro di Rational Application Developer V6.0.1.
- Creare un nuovo progetto portlet denominato JSFP601 con
l'opzione portlet Faces selezionata nella seconda
pagina. Questo progetto verrà utilizzato solo come origine per le
ultime risorse di runtime; può essere eliminato al termine
dell'aggiornamento.
- In Esplora progetti, selezionare con il tasto destro del mouse il progetto
JSFP601 e scegliere Proprietà dal menu.
- Scegliere Funzioni progetto Web e selezionare Aggiungi
Faces Client Framework per il progetto Portlet, quindi scegliere
OK.
- Per ciascun progetto Faces esistente da aggiornare, procedere come
segue:
- In Esplora progetti, espandere un progetto esistente in modo da
visualizzare i file nella cartella WebContent/WEB-INF/lib/. Individuare
ed eliminare i seguenti file JAR in questa directory:
- jsf-api.jar
- jsf-ibm.jar
- jsf-impl.jar
- jsf-portlet.jar
- odc-jsf.jar
- Individuare ed aprire il file
WebContent/WEB-INF/faces-config.xml. Aggiungere i seguenti
elementi nel file di configurazione, se non sono già presenti:
<lifecycle>
<phase-listener>com.ibm.faces.webapp.ValueResourcePhaseListener</phase-listener>
</lifecycle>
<application>
<variable-resolver>com.ibm.faces.databind.SelectItemsVarResolver</variable-resolver>
<variable-resolver>com.ibm.faces.application.WPPortletVariableResolver</variable-resolver>
<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
</application>
- Nota:
- Se il progetto portlet utilizza l'API JSR 168, specificare
com.ibm.faces.application.PortletVariableResolver
anziché
com.ibm.faces.application.WPPortletVariableResolver.
- Per tutti i file JAR eliminati, copiare il file JAR dello stesso nome
dalla directory WebContent/WEB-INF/lib del progetto JSFP601 e
incollarlo nel progetto originale nello stesso percorso. Alcune
configurazioni non richiedono che tutti questi file siano contenuti nel
progetto; non copiare i file JAR non presenti nel progetto
originale.
- Se il progetto portlet utilizza l'API portlet IBM o un componente di
collegamento Persona, copiare il file jsf-wp.jar nel progetto
originale.
- Se si copia il file odc-jsf.jar, copiare anche il file
odc-jsf-portlet.jar.
- Aprire il descrittore di distribuzione web.xml nel progetto
originale e aggiungere quanto segue alla configurazione:
<context-param>
<param-name>com.ibm.ws.jsf.JSP_UPDATE_CHECK</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>com.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP</param-name>
<param-value>true</param-value>
</context-param>
- Eliminare il progetto portlet JSFP601.
In Rational Application Developer V6.0, gli ambienti di test WAS
(WebSphere Application Server) inclusi con il prodotto sono stati modificati
rispetto agli ambienti di test inclusi con le edizioni precedenti di WebSphere
Studio Application Developer.
Di seguito viene riportato un riepilogo delle modifiche agli ambienti di
test WAS (WebSphere Application Server) in Rational Application Developer
V6.0:
- I server WAS (WebSphere Application Server) V4.x non sono più
supportati negli ambienti di test. Tuttavia, le applicazioni del
livello di specifica J2EE 1.2 possono essere ancora esportate e
distribuite manualmente per la verifica sui server V4.x remoti.
- Un server WAS (WebSphere Application Server) V6.0 è stato
aggiunto come un ambiente di test installabile. Tale server supporta
l'esecuzione delle applicazioni del livello di specifica J2EE
1.4.
- L'ambiente di test WebSphere Portal è stato aggiunto per la
verifica delle applicazioni portals e portlet.
Nella tabella di seguito riportata vengono illustrati i livelli degli
ambienti di test WAS (WebSphere Application Server) con le diverse versioni di
WebSphere Studio Application Developer e Rational Application
Developer.
Tabella 2. Ambienti di test WAS (WebSphere Application Server in WebSphere Studio Application Developer e Rational Application Developer
| WebSphere Application Server V4.x AEs
| WebSphere Application Server V5.x Base
| WebSphere Application Server Express 5.x
| WebSphere Application Server V5.x Portal
| WebSphere Application Server V6.0
|
WebSphere Studio Application Developer V5.1
| V4.0.6
| V5.0.2
| V5.0.2
| N/D
| N/D
|
WebSphere Studio Application Developer V5.1.1
| V4.0.7 + PQ78374
| V5.0.2 + PQ78374 +PQ78419, V5.1
| V5.0.2 & V5.1
| N/D
| N/D
|
WebSphere Studio Application Developer V5.1.2
| V4.0.7 + PQ78374
| V5.0.2 + PQ78374 +PQ78419, V5.1.0.3
| V5.0.2 & V5.1.0.3
| V5.0.2.3 Base + WebSphere Portal
V5.0.2.1
| N/D
|
Rational Application Developer V6.0
| N/D
| V5.0.x, V5.1.1
| V5.0.2 & V5.1.1
| V5.0.2.6 Base + WebSphere Portal
V5.0.2.2, V5.1.1 Base + WebSphere Portal
5.1
| V6.0
|
Copyright e informazioni particolari