IBM Rational Web 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 Web Developer V6.0
Capitolo 3. Migrazione di progetti J2EE
Capitolo 4. Modifiche negli ambienti di test di WebSphere
Questa documentazione fornisce istruzioni per la migrazione da WebSphere
Studio Site Developer V5.1.x a Rational Web Developer
V6.0.
Ulteriori informazioni sono disponibili nei seguenti argomenti:
Le informazioni relative all'utilizzo di Rational Web 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 Web 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 Web 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 Web 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 Web 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 Web Developer
V6.0. Tutti i progetti EGL vengono migrati senza questa
prospettiva in Rational Web 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 Web 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 Web
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:
- 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 Web 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 Web Developer
V6.0. Se le connessioni JDBC sono state create utilizzando il
driver DB2 Net JDBC, non sarà possibile riconnettersi a Rational Web
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 Site
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 Site Developer V5.1.x sono stati
installati plugin del fornitore, è necessario procurarsi i plugin
corrispondenti per V6.0 e reinstallarli.
- Se si utilizzano funzioni che richiedono Agent Controller, aggiornare tali
funzioni installando la versione fornita con Rational Web 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 Web Developer, lo spazio viene migrato
automaticamente. Una volta migrato, non è più possibile aprire lo
spazio di lavoro in WebSphere Studio Site 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 Web 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.
Un file .compatibility viene creato automaticamente nella directory
del progetto quando un progetto V5.1.x viene aperto nello spazio
di lavoro Rational Web Developer V6.0. Il file
.compatibility viene utilizzato da Rational Web 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 Site Developer V5.1.x, fare riferimento a Disabilitazione della compatibilità con WebSphere Studio V5.1.x.
Considerazioni su Eclipse
Questa versione di Rational Web 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 Web
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 Web 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
Web 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 Site 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 Web 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 Web
Developer V6.0 e WebSphere Studio Site 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 Web
Developer V6.0, la compatibilità dei progetti J2EE andrà perduta
e sarà necessario ristabilirla.
La compatibilità con WebSphere Studio Site Developer
V5.1.x può essere completamente rimossa da un progetto
applicazione enterprise creato in Rational Web 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 Site 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 Site Developer V5.1.x.
Le risorse di runtime di JavaServer Faces originariamente fornite con
WebSphere Studio Site Developer V5.1.x sono state aggiornate per
Rational Web 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 Web 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 Site Developer V5.1.x in
Rational Web 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 Site 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 Web 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 Site Developer V5.1.x sono
state aggiornate per Rational Web 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 Web 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 Site Developer
V5.1.x in Rational Web 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 Site 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 Web 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 Web
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 Web 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 Web 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 Site
Developer viene aperto in Rational Web 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 Web 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 Site
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
Web 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 Web Developer V6.0.
Se si migra uno spazio di lavoro da WebSphere Studio Site 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
Web 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 Web 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 Web 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 Web Developer V6.0 sono state
aggiornate per Rational Web 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 Web 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 Web Developer
V6.0.x in Rational Web 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 Web 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.
La procedura guidata Migrazione J2EE è stata aggiornata in Rational Web
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:
- La migrazione dei servizi Web sicuri (da J2EE 1.3 a 1.4)
richiede la migrazione manuale dei file di binding e di estensione
sicuri. Per i dettagli, fare riferimento a Migrazione di servizi Web sicuri.
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 Web 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.
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 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 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.
- 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 3, Migrazione di progetti J2EE.
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 Web 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 Web 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 Web 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.
In Rational Web 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
Site Developer.
Di seguito viene riportato un riepilogo delle modifiche agli ambienti di
test WAS (WebSphere Application Server) in Rational Web 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.
Nella tabella di seguito riportata vengono illustrati i livelli degli
ambienti di test WAS (WebSphere Application Server) con le diverse versioni di
WebSphere Studio Site Developer e Rational Web Developer.
Tabella 2. Ambienti di test WAS (WebSphere Application Server in WebSphere Studio Site Developer e Rational Web Developer
| WebSphere Application Server V4.x AEs
| WebSphere Application Server V5.x Base
| WebSphere Application Server Express V5.x
| WebSphere Application Server V6.0
|
| WebSphere Studio Site Developer V5.1
| V4.0.6
| V5.0.2
| V5.0.2
| N/D
|
| WebSphere Studio Site Developer V5.1.1
| V4.0.7 + PQ78374
| V5.0.2 + PQ78374 +PQ78419, V5.1
| V5.0.2 & V5.1
| N/D
|
| WebSphere Studio Site Developer V5.1.2
| V4.0.7 + PQ78374
| V5.0.2 + PQ78374 +PQ78419, V5.1.0.3
| V5.0.2 & V5.1.0.3
| N/D
|
| Rational Web Developer V6.0
| N/D
| V5.0.x, V5.1.1
| V5.0.2 & V5.1.1
| V6.0
|
Copyright e informazioni particolari