IBM Rational Web Developer per Windows e Linux, Versione 6.0 - Guida alla migrazione


Indice

Capitolo 1. Migrazione da WebSphere Studio V5.1, 5.1.1 o 5.1.2

  • Compatibilità con WebSphere Studio V5.1.x
  • Disabilitazione della compatibilità con WebSphere Studio V5.1.x
  • Aggiornamento delle risorse di runtime Faces in un progetto Web
  • Aggiornamento delle risorse di runtime Faces Client in un progetto Web
  • Migrazione dei progetti Web Struts
  • Modifiche al debugger in V6.0
  • Migrazione da WDO a SDO
  • Parole EGL riservate in V6.0
  • Capitolo 2. Aggiornamento delle risorse di runtime Faces per i progetti Web da Rational Web Developer V6.0

    Capitolo 3. Migrazione di progetti J2EE

  • Migrazione di servizi Web sicuri
  • Migrazione dal livello di specifica J2EE 1.3 a 1.4
  • Progetti Web (da servlet livello 2.3 a servlet livello 2.4)
  • Progetti di connessione (da JCA 1.0 a JCA 1.5)
  • Servizi Web (da J2EE 1.3 a J2EE 1.4)
  • Migrazione dal livello di specifica J2EE 1.2 a 1.4
  • Progetti Web (da servlet livello 2.2 a servlet livello 2.4)
  • Modifiche nella procedura guidata Migrazione J2EE in Rational Web Developer V6.0
  • Capitolo 4. Modifiche negli ambienti di test di WebSphere



    Capitolo 1. Migrazione da WebSphere Studio V5.1, 5.1.1 o 5.1.2

    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:

    1. 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.
    2. Eseguire il backup dello spazio di lavoro di WebSphere Studio V5.1.x.
    3. Installare Rational Web Developer. Fare riferimento alla Guida all'installazione (file install.html) disponibile nella directory principale del primo CD del prodotto.
    4. 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).
    5. 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:
      1. 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:

        1. Chiudere la prospettiva selezionando Finestra -> Chiudi prospettiva
        2. 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:
        1. Chiudere la prospettiva Web EGL.
        2. Abilitare le funzioni EGL nelle Preferenze (Finestra -> Preferenze). Per ulteriori informazioni sull'abilitazione delle funzioni EGL, fare riferimento alla guida in linea.
        3. Selezionare Finestra -> Apri prospettiva e scegliere la prospettiva Web.
      2. 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.
      3. 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:

      Importante:

    6. 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.
    7. 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.
    8. 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.
    9. 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.
    10. 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.

    Compatibilità con WebSphere Studio V5.1.x

    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:

    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:

    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:

    1. Aprire il file .classpath per ciascun progetto J2EE con un file .classpath.
    2. Eliminare le voci del percorso classi di seguito riportate dal file .classpath, quindi salvare e chiudere il file.
    3. 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".
    4. Fare clic con il tasto destro del mouse sul progetto e selezionare Proprietà -> J2EE.
    5. 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.
    6. 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.

    Disabilitazione della compatibilità con WebSphere Studio V5.1.x

    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:

    1. 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.
    2. 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.
    3. Fare clic su 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.


    Aggiornamento delle risorse di runtime Faces in un progetto Web

    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:

    1. 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.
    2. 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.
    3. Selezionare una delle seguenti opzioni:
    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:

    1. Importare il progetto Web esistente con contenuto Faces in uno spazio di lavoro Rational Web Developer V6.0.1.
    2. 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.
    3. In Esplora progetti, selezionare con il tasto destro del mouse il progetto JSF601 e scegliere Proprietà dal menu.
    4. Scegliere Funzioni progetto Web e selezionare Aggiungi componenti di base Faces e Aggiungi Faces Client Framework, quindi scegliere OK.
    5. Se si utilizza EGL, creare un file di pagina JSF come segue:
      1. Selezionare la cartella WebContent del nuovo progetto Web EGL.
      2. Selezionare Nuovo -> Altro -> File JSP Faces.
      I file eglintdebug.jar e eglintdebugsupport.jar sono stati aggiunti al progetto.
    6. Per ciascun progetto Faces esistente da aggiornare, procedere come segue:
      1. 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
      2. 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>
        
      3. 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.
      4. 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>
        
      5. Se il progetto originale utilizzava WebSphere Data Objects (WDO) per qualsiasi accesso ai dati, procedere come segue:
        1. Nel progetto originale, scegliere File -> Nuovo -> File JSP Faces per creare un nuovo file temporaneo JSP Faces.
        2. Trascinare un componente elenco di record relazionali dal cassetto Dati della tavolozza nella pagina.
        3. 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.
        4. Eliminare i file JSP temporanei.
      6. 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.
    7. Eliminare il progetto Web JSF601.

    Aggiornamento delle risorse di runtime Faces Client in un progetto Web

    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:

    1. 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.
    2. 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.
    3. Selezionare una delle seguenti opzioni:
    4. 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.
    5. Dalla cartella Risorse Java -> JavaSource nel progetto Web, aprire il file OdysseyBrowserFramework.properties ed eliminare le voci per EMAP_FILES e ECORE_FILES.
    6. Per ciascun oggetto dati nella vista Dati client:
      1. Fare clic con il tasto destro del mouse e selezionare Configura.
      2. 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:

    1. Completare le istruzioni riportate nella sezione Aggiornamento manuale delle risorse di runtime in Aggiornamento delle risorse di runtime Faces in un progetto Web.
    2. 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:

    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:

    1. Generare i nuovi gestori e processori Diff in ciascun oggetto dati client nel progetto Web.
      1. Selezionare l'oggetto dati client con il tasto destro del mouse e scegliere Configura.
      2. Nella scheda Avanzate, scegliere Rigenera tutto.
    2. 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";
      
    3. 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.

    Modifiche ai componenti client Faces nella V6.0:


    Migrazione dei progetti Web Struts

    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:

    1. Aprire il progetto Web Struts in Esplora progetti.
    2. Fare doppio clic sul file Descrittore di distribuzione del progetto Web in Esplora progetti. Viene aperto l'editor del descrittore di distribuzione Web.
    3. Fare clic sulla scheda Origine per aprire la pagina Origine.
    4. 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> .

    5. 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:

    1. Caricare i progetti Struts 1.1 nello spazio di lavoro Rational Web Developer V6.0.
    2. 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.
    3. Per ciascun progetto Struts 1.1 Beta che si desidera convertire in Struts 1.1, procedere come segue:
      1. Eliminare i seguenti file JAR dalla directory Content/WEB-INF/lib del progetto Web:
        • commons-*.jar.
        • struts.jar.
      2. 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.
      3. Eliminare i seguenti file TLD (Tag Library Descriptor) dalla directory Content/WEB-INF del progetto Web: struts-*.tld.
      4. 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:

    1. Caricare i progetti Struts 1.0.2 in uno spazio di lavoro Rational Web Developer V6.0.
    2. 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.
    3. Per ciascun progetto Struts 1.0.2 che si desidera convertire in Struts 1.1, procedere come segue:
      1. Eliminare i file struts.jar dalla directory Content/WEB-INF/lib del progetto Web.
      2. 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.
      3. Eliminare i seguenti file TLD (Tag Library Descriptor) dalla directory Content/WEB-INF del progetto Web: struts-*.tld.
      4. Copiare i seguenti file TLD dalla directory Struts11/WebContent/WEB-INF nella directory Content/WEB-INF del progetto Web: struts-*.tld.

    Modifiche al debugger in V6.0

    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:

    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:


    Migrazione da WDO a SDO

    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:

    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à

    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:

    1. 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;
      
    2. 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:

    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:

    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

    Parole EGL riservate in V6.0

    Nuove parole riservate sono presenti in EGL (Enterprise Generation Language), in Rational Web Developer.

    Le nuove parole riservate sono di seguito riportate:

    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.


    Capitolo 2. Aggiornamento delle risorse di runtime Faces per i progetti Web da Rational Web Developer V6.0

    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:

    1. 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.
    2. 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.
    3. Selezionare una delle seguenti opzioni:

    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:

    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.
    2. In Esplora progetti, selezionare con il tasto destro del mouse il progetto JSF601 e scegliere Proprietà dal menu.
    3. Scegliere Funzioni progetto Web e selezionare Aggiungi componenti di base Faces e Aggiungi Faces Client Framework, quindi scegliere OK.
    4. Se si utilizza EGL, creare un file di pagina JSF come segue:
      1. Selezionare la cartella WebContent del nuovo progetto Web EGL.
      2. Selezionare Nuovo -> Altro -> File JSP Faces.
      I file eglintdebug.jar e eglintdebugsupport.jar sono stati aggiunti al progetto.
    5. Per ciascun progetto Faces esistente da aggiornare, procedere come segue:
      1. 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
      2. 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.
      3. 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.
    6. Eliminare il progetto Web JSF601.

    Capitolo 3. Migrazione di progetti J2EE

    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:

    È possibile accedere alla procedura guidata Migrazione J2EE come segue:

    1. Nella vista Gerarchia J2EE della prospettiva J2EE, selezionare con il tasto destro del mouse il progetto dell'applicazione enterprise che si desidera migrare.
    2. Selezionare Migra -> Procedura guidata Migrazione J2EE dal menu a comparsa.
    3. 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 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.


    Migrazione di servizi Web sicuri

    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:

    1. Fare doppio client sul file webservices.xmlper aprire l'editor Servizi Web.
    2. Selezionare la scheda Configurazioni binding per modificare il file di binding.
    3. 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.
    4. Selezionare la scheda Estensione per modificare il file di estensione.
    5. 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.
    6. Salvare e chiudere l'editor.

    Migrazione dal livello di specifica J2EE 1.3 a 1.4

    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.

    Progetti Web (da servlet livello 2.3 a servlet livello 2.4)

    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.

    Progetti di connessione (da JCA 1.0 a JCA 1.5)

    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.

    Servizi Web (da J2EE 1.3 a J2EE 1.4)

    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:

    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:

    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.


    Migrazione dal livello di specifica J2EE 1.2 a 1.4

    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.

    Progetti Web (da servlet livello 2.2 a servlet livello 2.4)

    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.


    Modifiche nella procedura guidata Migrazione J2EE in Rational Web Developer V6.0

    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.


    Capitolo 4. Modifiche negli ambienti di test di WebSphere

    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:

    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