IBM Rational Application 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 Application Developer V6.0

    Capitolo 3. Aggiornamento delle risorse di runtime Faces per i progetti portlet da Rational Application Developer V6.0

    Capitolo 4. Migrazione di progetti J2EE

  • Migrazione di servizi Web sicuri
  • Migrazione dal livello di specifica J2EE 1.3 a 1.4
  • Progetti Enterprise JavaBean (da EJB 2.0 a EJB 2.1)
  • 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
  • Migrazione dei progetti Enterprise JavaBeans (da EJB 1.1 a EJB 2.1)
  • Progetti Web (da servlet livello 2.2 a servlet livello 2.4)
  • Modifiche nella procedura guidata Migrazione J2EE in Rational Application Developer V6.0
  • Capitolo 5. Migrazione agli strumenti Portal in Rational Application Developer V6.0

  • Migrazione dei portlet WebSphere Portal da V4.2 a V5.x
  • Aggiornamento delle risorse di runtime Faces in un progetto portlet
  • Capitolo 6. Modifiche negli ambienti di test di WebSphere



    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 Application Developer V5.1.x a Rational Application Developer V6.0.

    Ulteriori informazioni sono disponibili nei seguenti argomenti:

    Le informazioni relative all'utilizzo di Rational Application Developer sono disponibili nella guida in linea.

    Per documentazione aggiornata, fare riferimento alla pagina www.ibm.com/developerworks/rational.

    Per informazioni sulla migrazione dalle versioni precedenti di WebSphere Studio a v5.x o sulla migrazione da VisualAge per Java a WebSphere Studio, visitare il sito www.ibm.com/software/awdtools/studioappdev/support/ e ricercare "guida alla migrazione".

    Per eseguire la migrazione da WebSphere Studio V5.1.x:

    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 Application 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 Application Developer, viene richiesto di confermare che si desidera utilizzare uno spazio di lavoro denominato rationalsdp6.0\workspace. Ciò significa che la finestra di dialogo Utilità di avvio spazio di lavoro indica una directory che non corrisponde allo spazio di lavoro WebSphere Studio. Per esplorare il nuovo ambiente prima di migrare il vecchio spazio di lavoro, accettare l'impostazione predefinita o specificare un nuovo nome di directory quando si avvia Rational Application Developer. Si consiglia di eseguire questa operazione, ad esempio, per creare uno o due progetti di test, individuare il nuovo progetto (Guida -> Benvenuti), eseguire alcune nuove esercitazioni (Guida -> Galleria di esercitazioni) o provare alcuni nuovi esempi (Guida -> Galleria di esempi).
    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 Application Developer con il vecchio spazio di lavoro. Un indicatore di avanzamento conferma che i progetti vengono migrati automaticamente.

        Note: Durante la migrazione dello spazio di lavoro, si apre una finestra di dialogo Problemi con il messaggio Impossibile ripristinare il layout del workbench. Motivo: Problemi durante il ripristino del workbench. I messaggi di errore non hanno alcun impatto sulla migrazione dello spazio di lavoro. Annotare il nome della prospettiva che non può essere ripristinata facendo clic sul pulsante Dettagli nella finestra di dialogo di errore, quindi facendo clic su OK per chiudere la finestra di dialogo.

        Per ripristinare la prospettiva:

        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 Application Developer V6.0. Tutti i progetti EGL vengono migrati senza questa prospettiva in Rational Application Developer V6.0. Se è stata utilizzata la prospettiva Web EGL, procedere come segue:
        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 Application 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 Application Developer V6.0 utilizzando la funzione Project Interchange vengono migrati automaticamente a V6.0. La funzione Project Interchange era disponibile in WebSphere Studio V5.1.2 ed era un plugin facoltativo per V5.1.1.

      Note:

      Importante:

    6. Il driver DB2 Net JDBC non è supportato in Rational Application Developer V6.0. Se le connessioni JDBC sono state create utilizzando il driver DB2 Net JDBC, non sarà possibile riconnettersi a Rational Application Developer V6.0. Per utilizzare uno dei driver JDBC supportati, è necessario modificare la connessione. Per ulteriori informazioni sui driver JDBC supportati in V6.0, fare riferimento alla guida in linea.
    7. Se il contenuto file Web o XML è stato migrato da WebSphere Studio Application Developer V5.1.x, in cui è stato utilizzato l'insieme di caratteri Shift_JIS e sono stati inclusi i caratteri selezionati dal fornitore, è necessario specificare l'insieme di caratteri Windows-31J.
    8. Se con WebSphere Studio Application Developer V5.1.x sono stati installati plugin del fornitore, è necessario procurarsi i plugin corrispondenti per V6.0 e reinstallarli.
    9. Se con l'installazione di Rational Application Developer sono stati installati ambienti di test dell'unità WebSphere V5.x di livello precedente e se è stato utilizzato il servizio di messaggistica incorporato, aggiornare il servizio installando la versione fornita con Rational Application Developer. Per i dettagli sull'installazione del servizio di messaggistica incorporato, fare riferimento alla guida all'installazione.
    10. Se si utilizzano funzioni che richiedono Agent Controller, aggiornare tali funzioni installando la versione fornita con Rational Application Developer. Per i dettagli, fare riferimento alla guida all'installazione.
    11. 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 Application Developer, lo spazio viene migrato automaticamente. Una volta migrato, non è più possibile aprire lo spazio di lavoro in WebSphere Studio Application Developer. Tuttavia, i progetti dello spazio di lavoro V6.0 possono ancora essere condivisi con WebSphere Studio V5.1.x, utilizzando un sistema SCM (source code management) (ad esempio Rational ClearCase) importando ed esportando il progetto mediante Project Interchange, o mediante l'importazione di archivi e l'esportazione di progetti. Importante: le applicazioni portlet da Portal Toolkit V5.0.2.2 migrate agli strumenti del portale in Rational Application Developer V6.0 non sono compatibili.

    Nota:
    Le informazioni di seguito riportate non vengono applicate ai progetti di applicazione portlet.

    I progetti V5.1.x esistenti caricati da un sistema SCM o da un altro programma di sviluppo in Project saranno compatibili per la condivisione con V5.1.x, se non viene effettuata una delle seguenti azioni:

    Un file .compatibility viene creato automaticamente nella directory del progetto quando un progetto V5.1.x viene aperto nello spazio di lavoro Rational Application Developer V6.0. Il file .compatibility viene utilizzato da Rational Application Developer per tracciare la data/ora delle risorse del progetto, quando tali risorse vengono migrate. Si consiglia di non modificare o eliminare questo file.

    Per informazioni sulla disabilitazione della compatibilità con WebSphere Studio Application Developer V5.1.x, fare riferimento a Disabilitazione della compatibilità con WebSphere Studio V5.1.x.

    Considerazioni su Eclipse

    Questa versione di Rational Application Developer si basa su Eclipse V3.0. Se si sviluppano i plug-in, è necessario acquisire informazioni sulle modifiche alla piattaforma prima della migrazione.

    Per i dettagli, fare riferimento al file readme nella sottodirectory eclipse\readme del percorso di installazione di Rational Application Developer V6.0. Le sezioni del file readme di interesse per la migrazione sono:

    Compatibilità dei progetti J2EE

    La compatibilità dei progetti creati in WebSphere Studio V5.1.x con Rational Application Developer V6.0 è abilitata per mezzo dei metadati automaticamente aggiunti ai file .project, quando si migra lo spazio di lavoro V5.1.x. Allo stesso modo, se si crea un nuovo modulo o applicazione J2EE 1.2 o 1.3 in Rational Application Developer V6.0, i metadati di generazione vengono aggiunti automaticamente al file .project per la compatibilità con V5.1.x. Non modificare o eliminare queste informazioni direttamente.

    Nota:
    I metadati di compatibilità generano la visualizzazione o la registrazione di messaggi sui "generatori mancanti" quando un nuovo modulo o applicazione J2EE 1.2 e J2EE 1.3 creati in V6.0 vengono utilizzati in WebSphere Studio Application Developer V5.1.x, laddove i generatori V6.0 non sono disponibili. Questi messaggi sono normali ed è possibile ignorarli.

    Fino a quando sono presenti metadati di compatibilità, verranno visualizzati messaggi relativi a "generatori mancanti", quando i progetti Rational Application Developer V6.0 vengono ricaricati in WebSphere Studio V5.1.x. Di seguito viene riportato un esempio di messaggio relativo a un "generatore mancante":

    !ENTRY org.eclipse.core.resources 2 1 Sep 06, 2004 19:55:20.592
    !MESSAGE Skipping builder com.ibm.wtp.j2ee.LibCopyBuilder for project Test60EARWeb. 
    Il generatore non è presente nell'installazione o appartiene a un progetto mancante o disabilitato.
    

    Questi messaggi sono normali ed è possibile ignorarli. Quando si è certi che non sia più necessario gestire un determinato progetto in WebSphere Studio V5.1.x, è possibile arrestare i messaggi disabilitando la compatibilità con le versioni precedenti per quel progetto.

    Importante: nuovi progetti di specifica J2EE 1.2 o 1.3 creati in V6.0 sono compatibili con WebSphere Studio V5.1.x, ma, una volta caricato il progetto in WebSphere Studio, per poter gestire il progetto è necessaria una procedura manuale. Questa procedura è necessaria perché le destinazioni di runtime sui nuovi progetti di specifica J2EE 1.2 o 1.3 creati in 6.0 non sono direttamente compatibili con i server di destinazione in V5.1.x. La procedura manuale dopo il caricamento di un nuovo progetto V6.0 in V5.1.x è la seguente:

    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 Application Developer V6.0 e WebSphere Studio Application Developer V5.1.x. Una volta sottoposte a commit le modifiche nel sistema SCM, i progetti J2EE saranno interscambiabili tra V5.1.x e V6.0 utilizzando un sistema SCM.
      Nota:
      Se il server di destinazione è impostato di nuovo in Rational Application Developer V6.0, la compatibilità dei progetti J2EE andrà perduta e sarà necessario ristabilirla.

    Compatibilità del diagramma UML

    I diagrammi UML presenti in WebSphere Studio Application Developer V5.1.x sono compatibili e possono essere aperti in modalità di sola lettura in Rational Application Developer V6.0. In V6.0, la procedura guidata Migrazione J2EE consente di migrare automaticamente i diagrammi UML creati nei progetti J2EE V5.1.x durante la migrazione della struttura del progetto J2EE. Una volta migrati, i diagrammi UML possono essere modificati in Rational Application Developer V6.0.

    Nota:
    I diagrammi UML migrati in uno spazio di lavoro o creati in Rational Application Developer V6.0 non possono essere aperti in WebSphere Studio Application Developer V5.1.x.

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

    La compatibilità con WebSphere Studio Application Developer V5.1.x può essere completamente rimossa da un progetto applicazione enterprise creato in Rational Application Developer V6.0 o da un progetto applicazione enterprise migrato da una versione precedente di WebSphere Studio. È necessario disabilitare la compatibilità con WebSphere Studio V5.1.x solo se si è certi che il progetto applicazione enterprise non deve essere più interagibile o compatibile con V5.1.x.

    Per rimuovere la compatibilità con WebSphere Studio Application Developer V5.1.x:

    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 Application 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 Application Developer V5.1.x sono state aggiornate per Rational Application Developer V6.0.1. Se si desidera continuare lo sviluppo in progetti Web creati con la versione precedente del prodotto, si consiglia di aggiornare le risorse di runtime Faces all'ultimo livello.

    In Rational Application Developer V6.0.1, gli aggiornamenti alle risorse di runtime Faces vengono effettuati automaticamente quando viene importato un progetto o quando viene aperto uno spazio di lavoro che contiene risorse obsolete. Dopo aver importato un progetto Web o aver aperto uno spazio di lavoro da WebSphere Studio Application Developer V5.1.x in Rational Application Developer V6.0.1, verrà richiesto di aggiornare le risorse di runtime Faces all'ultimo livello.

    Aggiornamento automatico delle risorse di runtime

    Per aggiornare le risorse di runtime Faces automaticamente per i progetti Web, procedere come segue:

    1. Importare un progetto Web (o uno spazio di lavoro) contenente dati Faces da WebSphere Studio Application Developer V5.1.x. Viene aperta la finestra Migrazione progetto.
      Nota:
      Se la finestra Migrazione progetto non viene visualizzata, probabilmente l'impostazione di generazione automatica è disabilitata. In Esplora progetti, selezionare il progetto Web con il tasto destro del mouse e scegliere Genera -> Progetto; il processo di rigenerazione di un progetto apre la finestra Migrazione progetto.
    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 Application 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 Application Developer V5.1.x sono state aggiornate per Rational Application Developer V6.0.1. Se si desidera continuare lo sviluppo in progetti Web creati con la versione precedente del prodotto, si consiglia di aggiornare le risorse di runtime Faces Client all'ultimo livello.

    In Rational Application Developer V6.0.1, gli aggiornamenti alle risorse di runtime del client Faces vengono effettuati automaticamente quando viene importato un progetto o quando viene aperto uno spazio di lavoro che contiene risorse obsolete. Dopo aver importato un progetto Web o aver aperto uno spazio di lavoro da WebSphere Studio Application Developer V5.1.x in Rational Application Developer V6.0.1, verrà richiesto di aggiornare le risorse di runtime del client Faces all'ultimo livello.

    Aggiornamento automatico delle risorse di runtime

    Per aggiornare le risorse di runtime del client Faces automaticamente per i progetti Web, procedere come segue:

    1. Importare un progetto Web (o uno spazio di lavoro) contenente dati Faces Client da WebSphere Studio Application Developer V5.1.x. Viene aperta la finestra Migrazione progetto.
      Nota:
      Se la finestra Migrazione progetto non viene visualizzata, probabilmente l'impostazione di generazione automatica è disabilitata. In Esplora progetti, selezionare il progetto Web con il tasto destro del mouse e scegliere Genera -> Progetto; il processo di rigenerazione di un progetto apre la finestra Migrazione progetto.
    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 Application Developer V6.0 aggiungerà il carattere "/" quando viene creato un nuovo progetto Struts; tuttavia tale carattere deve essere aggiunto manualmente durante la migrazione da WebSphere Studio V5.1x.

    Per correggere il descrittore di distribuzione di un progetto Web Struts creato in WebSphere Studio v5.1.x per la versione 6.0, procedere come segue:

    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 Application 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 Application 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 Application Developer V6.0, sono state apportate diverse modifiche agli strumenti di debug. Per utilizzare questi strumenti con i progetti, dopo la migrazione, è necessario conoscere tali modifiche. Potrebbe essere necessario modificare o ripristinare le impostazioni.

    Migrazione di spazi di lavoro e configurazioni di avvio

    Quando uno spazio di lavoro V5.1.x di WebSphere Studio Application Developer viene aperto in Rational Application Developer V6.0, le configurazioni di avvio del debugger di seguito riportate associate allo spazio di lavoro non vengono migrate automaticamente:

    Viste di debug

    Le viste Memoria e Associazione memoria non esistono più. Tali viste sono state sostituite dalle viste Memoria e Rendering della memoria.

    Debugger XSLT

    Il debugger XSLT è stato modificato in V6.0, insieme a molte viste ed azioni. Per ulteriori informazioni, fare riferimento alla documentazione relativa al debugger XSLT nel centro informazioni.

    Una delle modifiche più significative nel debugger XSLT è la dipendenza dal JRE installato con Rational Application Developer V6.0. Se si migra uno spazio di lavoro da WebSphere Studio Application Developer V5.1.x, è necessario modificare il JRE installato affinché indichi il percorso corretto, prima di avviare una sessione di debug XSLT. Per questa operazione, è possibile eseguire una delle seguenti azioni:


    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 Application 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 Application 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 Application Developer V6.0

    Le risorse di runtime di JavaServer Faces e del client Faces originariamente fornite in Rational Application Developer V6.0 sono state aggiornate per Rational Application Developer V6.0.1. Se si desidera continuare lo sviluppo in progetti Web creati con la versione precedente del prodotto, si consiglia di aggiornare le risorse di runtime Faces e del client Client all'ultimo livello.

    In Rational Application Developer V6.0.1, gli aggiornamenti alle risorse di runtime Faces e del client Faces vengono effettuati automaticamente quando viene importato un progetto Web o quando viene aperto uno spazio di lavoro che contiene risorse obsolete. Dopo aver importato un progetto Web o aver aperto uno spazio di lavoro da Rational Application Developer V6.0.x in Rational Application Developer V6.0.1, verrà richiesto di aggiornare queste risorse di runtime Faces all'ultimo livello.

    Aggiornamento automatico delle risorse di runtime

    Per aggiornare le risorse di runtime Faces e del client Faces automaticamente per i progetti Web, procedere come segue:

    1. Importare un progetto Web (o uno spazio di lavoro) contenente dati Faces o del client Faces da Rational Application Developer V6.0. Viene aperta la finestra Migrazione progetto.
      Nota:
      Se la finestra Migrazione progetto non viene visualizzata, probabilmente l'impostazione di generazione automatica è disabilitata. In Esplora progetti, selezionare il progetto Web con il tasto destro del mouse e scegliere Genera -> Progetto; il processo di rigenerazione di un progetto apre la finestra Migrazione progetto.
    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. Aggiornamento delle risorse di runtime Faces per i progetti portlet da Rational Application Developer V6.0

    Le risorse di runtime di JavaServer Faces e del client Faces originariamente fornite in Rational Application Developer V6.0 sono state aggiornate per Rational Application Developer V6.0.1. Se si desidera continuare lo sviluppo in progetti portlet creati con la versione precedente del prodotto, si consiglia di aggiornare le risorse di runtime Faces e del client Client all'ultimo livello.

    In Rational Application Developer V6.0.1, gli aggiornamenti alle risorse di runtime Faces e del client Faces vengono effettuati automaticamente quando viene importato un progetto portlet o quando viene aperto uno spazio di lavoro che contiene risorse obsolete. Dopo aver importato un progetto portlet o aver aperto uno spazio di lavoro da Rational Application Developer V6.0 in Rational Application Developer V6.0.1, verrà richiesto di aggiornare queste risorse di runtime Faces all'ultimo livello.

    Aggiornamento automatico delle risorse di runtime

    Per aggiornare le risorse di runtime Faces e del client Faces automaticamente per i progetti portlet, procedere come segue:

    1. Importare un progetto portlet (o uno spazio di lavoro) contenente dati Faces o del client Faces da Rational Application Developer V6.0. Viene aperta la finestra Migrazione progetto.
      Nota:
      Se la finestra Migrazione progetto non viene visualizzata, probabilmente l'impostazione di generazione automatica è disabilitata. In Esplora progetti, selezionare il progetto portlet con il tasto destro del mouse e scegliere Genera -> Progetto; il processo di rigenerazione di un progetto apre la finestra Migrazione progetto.
    2. Se si dispone di altri progetti portlet con contenuto Faces o del client Faces nello spazio di lavoro, selezionare l'opzione Applica questa scelta a tutti i progetti che devono essere aggiornati in modo che vengano aggiornati tutti i progetti portlet.
    3. Selezionare una delle seguenti opzioni:
    4. Per aggiornare le risorse di runtime Faces specifiche del portlet, jsf-portlet.jar e jsf-wp.jar, sarà necessario seguire le istruzioni per l'aggiornamento manuale riportate di seguito.

    Aggiornamento manuale delle risorse di runtime

    Per aggiornare le risorse di runtime Faces e del client Faces manualmente per i progetti portlet, procedere come segue:

    1. Creare un nuovo progetto portlet chiamato JSFP601. Questo progetto verrà utilizzato solo come origine per le ultime risorse di runtime; può essere eliminato al termine dell'aggiornamento.
    2. In Esplora progetti, selezionare con il tasto destro del mouse il progetto JSFP601 e scegliere Proprietà dal menu.
    3. Scegliere Funzioni progetto Web e selezionare Aggiungi Faces Client Framework per il progetto Portlet, quindi scegliere OK.
    4. Per ciascun progetto portlet 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:
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • jsf-portlet.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 JSFP601 e incollarlo nel progetto originale nello stesso percorso. Alcune configurazioni non richiedono che tutti questi file siano contenuti nel progetto; non copiare i file JAR non presenti nel progetto originale.
        • Se il progetto portlet utilizza l'API portlet IBM o un componente di collegamento Persona, copiare il file jsf-wp.jar nel progetto originale.
        • Se si copia il file odc-jsf.jar, copiare anche il file odc-jsf-portlet.jar.
    5. Eliminare il progetto portlet JSFP601.

    Capitolo 4. Migrazione di progetti J2EE

    La procedura guidata Migrazione J2EE è stata aggiornata in Rational Application Developer V6.0 per migrare i progetti J2EE nel livello di specifica J2EE 1.4. La procedura guidata Migrazione J2EE supporta la migrazione dalle specifiche J2EE 1.2 e 1.3 al livello di specifica J2EE 1.4, per tutti i tipi di moduli J2EE.

    Per i dettagli sulla migrazione delle risorse del livello di specifica J2EE 1.2 e 1.3 al livello di specifica J2EE 1.4, fare riferimento a Migrazione dal livello di specifica J2EE 1.3 a 1.4 e Migrazione dal livello di specifica J2EE 1.2 a 1.4.

    Nota:
    Prima di utilizzare la procedura guidata Migrazione J2EE, attenersi alla seguente procedura:

    È 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 Application Developer V6.0.

    Per i dettagli sulle modifiche alle risorse del livello di specifica J2EE 1.2 e 1.3 durante al migrazione al livello di specifica J2EE 1.4, fare riferimento a Migrazione dal livello di specifica J2EE 1.3 a 1.4 e Migrazione dal livello di specifica J2EE 1.2 a 1.4.


    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 Enterprise JavaBean (da EJB 2.0 a EJB 2.1)

    La procedura guidata Migrazione J2EE supporta la migrazione dei descrittori di distribuzione bean enterprise dalla risorsa EJB del livello di specifica J2EE 1.3 al livello di specifica J2EE 1.4. I bean di sessione privi di stato e i bean basati sui messaggi vengono migrati a J2EE 1.4.

    Migrazione di bean di sessione

    La procedura guidata Migrazione J2EE consente di migrare i bean di sessione privi di stato definiti come SEI (service endpoint interfaces) nel descrittore webservices.xml di un progetto EJB dal livello di specifica J2EE 1.3 al livello di specifica J2EE 1.4, impostando nuove SEI (service endpoint interfaces) nel bean di sessione privo di stato.

    La specifica J2EE 1.4 richiede che una SEI sia definita in un bean di sessione privo di stato, se il bean di sessione deve essere utilizzato come endpoint dei servizi Web. Durante la migrazione di un file JAR EJB, in tutti i bean di sessione del progetto EJB l'endpoint del servizio viene impostato sul nome utilizzato nel descrittore webservices.xml del progetto EJB. Di seguito viene riportato un esempio di come i metadati di un progetto EJB appaiono prima e dopo la migrazione al livello di specifica J2EE 1.4.

    Progetto EJB in J2EE 1.3: descrittore webservices.xml con bean di sessione privo di stato utilizzato come service endpoint interface Web prima della migrazione

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE webservices PUBLIC "-//IBM Corporation, Inc.//DTD J2EE Web services 1.0//EN" 
    "http://www.ibm.com/webservices/dtd/j2ee_web_services_1_0.dtd">
       <webservices id="WebServices_1084831328093">
          <webservice-description id="WebServiceDescription_1084831328093">
             <webservice-description-name>EchoEJBService</webservice-description-name>
             <wsdl-file>META-INF/wsdl/EchoEJB.wsdl</wsdl-file>
             <jaxrpc-mapping-file>META-INF/EchoEJB_mapping.xml</jaxrpc-mapping-file>
             <port-component id="PortComponent_1084831328103">
                <port-component-name>EchoEJB</port-component-name>
                <wsdl-port id="WSDLPort_1084831328103">
                   <namespaceURI>http://test</namespaceURI>
                   <localpart>EchoEJB</localpart>
                </wsdl-port>
                <service-endpoint-interface>test.EchoEJB</service-endpoint-interface>
                <service-impl-bean id="ServiceImplBean_1084831328103">
                   <ejb-link>EchoEJB</ejb-link>
                </service-impl-bean>
             </port-component>
          </webservice-description>
       </webservices>
    

    I tag <service-endpoint-interface> e <service-impl-bean> dell'esempio precedente definiscono il bean di sessione privo di stato "EchoEJB" come endpoint di un servizio nel descrittore dei servizi Web a livello di specifica J2EE 1.3 prima della migrazione.

    Progetto EJB in J2EE 1.4: descrittore di distribuzione EJB per il bean di sessione privo di stato "EchoEJB" con service endpoint interface creata dal processo di migrazione

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE ejb-jar>
    <ejb-jar id="ejb-jar_ID" version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
    	<display-name>
    	EchoEJBProject</display-name>
    	<enterprise-beans>
    		<session id="EchoEJB">
    			<ejb-name>EchoEJB</ejb-name>
    			<home>test.EchoEJBHome</home>
    			<remote>test.EchoEJB</remote>
    			<service-endpoint>test.EchoEJB</service-endpoint>
    			<ejb-class>test.EchoEJBBean</ejb-class>
    			<session-type>Stateless</session-type>
    			<transaction-type>Container</transaction-type>
    		</session>
    	</enterprise-beans>
    </ejb-jar>
    

    Il tag <service-endpoint> dell'esempio precedente definisce "EchoEJB" come endpoint di un servizio nel livello di specifica J2EE 1.4 dopo la migrazione.

    Migrazione di bean basati sui messaggi

    La procedura guidata Migrazione J2EE supporta la migrazione dei bean basati sui messaggi di EJB 2.0 a EJB 2.1.

    I bean basati sui messaggi sono stati introdotti in EJB 2.0 per supportare l'elaborazione di messaggi asincroni da un JMS (Java Message Service). La specifica EJB 2.1 espande la definizione di bean basato sui messaggi in modo che possa supportare qualsiasi sistema di messaggistica, non solo JMS.

    Nota:
    I bean basati sui messaggi migrati dal livello di specifica EJB 2.0 a EJB 2.1 e distribuiti su to WebSphere Application Server versione 6 devono essere distribuiti su un adattatore di risorse JCA (Java Connector Architecture) 1.5 invece che su una porta listener (come in WebSphere Application Server versione 5). Affinché i bean basati sui messaggi EJB 2.1 utilizzino un adattatore JCA, è necessario utilizzare l'editor descrittore di distribuzione per modificare le impostazioni di binding WebSphere. Vedere Configurazione di un bean basato sui messaggi EJB 2.1 affinché utilizzi un adattatore JCA.

    Le risorse migrate dei bean basati sui messaggi EJB 2.0 sono:

    Alcuni elementi di bean basati sui messaggi EJB 2.0 vengono sostituiti con le proprietà activation-config. I nomi delle proprietà ed i valori utilizzati nella proprietà activation-config per descrivere il servizio di messaggistica variano in base al tipo di servizio di messaggistica utilizzato. Tuttavia, EJB 2.1 definisce un insieme di proprietà fisse per i bean basati sui messaggi JMS.

    Nell'esempio di seguito riportato, gli elementi di un bean di esempio in EJB 2.0 vengono confrontati con il modo in cui gli elementi vengono visualizzati in EJB 2.1

    Un esempio di elementi di un bean basato sui messaggi in EJB 2.0:

    <message-driven id="Mdb20">
    	  <ejb-name>Mdb</ejb-name>
    	  <ejb-class>ejbs.MdbBean</ejb-class>
    	  <transaction-type>Bean</transaction-type>
    	  <message-selector>mdbMessage</message-selector>
    	  <acknowledge-mode>Auto-acknowledge</acknowledge-mode>
    	  <message-driven-destination>
    		<destination-type>javax.jms.Topic</destination-type>
    		<subscription-durability>Durable</subscription-durability>
    	   </message-driven-destination>
    </message-driven>
    

    Un esempio di elementi di un bean basato sui messaggi in EJB 2.1:

        <message-driven id="Mdb21">
      <ejb-name>Foo/ejb-name>
      <ejb-class>ejbs.FooBean</ejb-class>
       <messaging-type>javax.jms.MessageListener</messaging-type>
       <transaction-type>Bean/transaction-type>
       <message-destination-type>javax.jms.Topic</message-destination-type>
        <activation-config>
    	  <activation-config-property>
    	   <activation-config-property-name>destinationType</activation-config-property-name>
    	   <activation-config-property-value>javax.jms.Topic</activation-config-property-value>
    	  </activation-config-property>
    	  <activation-config-property>
    	   <activation-config-property-name>subscriptionDurability</activation-config-property-name>
    	     <activation-config-property-value>Durable</activation-config-property-value>
    	  </activation-config-property>
    	  <activation-config-property>
    	     <activation-config-property-name>acknowledgeMode</activation-config-property-name>
    	     <activation-config-property-value>AutoAcknowledge</activation-config-property-value>
    	  </activation-config-property>
    	  <activation-config-property>
    		<activation-config-property-name>messageSelector</activation-config-property-name>
    		<activation-config-property-value>fooSelector</activation-config-property-value>
    	  </activation-config-property>
    </activation-config>
    </message-driven>
    

    Configurazione di un bean basato sui messaggi EJB 2.1 affinché utilizzi un adattatore JCA

    I bean basati sui messaggi migrati da EJB (Enterprise Java Bean) 2.0 al livello di specifica EJB 2.1 e sono distribuiti su WebSphere Application Server versione 6, devono essere distribuiti su un adattatore di risorse JCA (Java Connector Architecture) 1.5 invece che su una porta listener.

    Di seguito viene descritto come modificare il descrittore di distribuzione dei bean basati sui messaggi EJB 2.1 affinché utilizzi un adattatore JCA:

    1. Aprire il progetto EJB in Esplora progetti.
    2. Fare doppio clic sul file Descrittore di distribuzione del progetto EJB in Esplora progetti. Viene aperto l'editor del descrittore di distribuzione EJB.
    3. Scegliere la scheda Bean e aprire la pagina Bean.
    4. Per ciascun bean basato sui messaggi EJB 2.1 nel progetto, procedere come segue:
      1. Selezionare il bean basato sui messaggi EJB 2.1 nell'elenco di bean situato a sinistra nella pagina Bean.
      2. Nell'intestazione Binding WebSphere, selezionare il pulsante Adattatore JCA.
      3. Specificare le proprietà di distribuzione dei binding:
        1. Nome JNDI ActivationSpec.

          Indicare il nome JNDI della specifica di attivazione J2C da utilizzare per distribuire questo bean basato sui messaggi. Questo nome deve corrispondere al nome di una specifica di attivazione J2C definita in WebSphere Application Server.

        2. Alias autorizzazione ActivationSpec.

          Il nome dell'alias di autenticazione J2C utilizzato per l'autenticazione delle connessioni per l'adattatore di risorse JCA. Gli alias di autenticazione J2C indicano l'ID utente e la password da utilizzare per autenticare la creazione di una nuova connessione all'adattatore di risorse JCA.

        3. Nome JNDI di destinazione.

          Indicare il nome JNDI che il bean basato sui messaggi utilizzerà per ricercare la destinazione JMS nello spazio nomi JNDI.

    5. Salvare le modifiche e chiudere l'editor del descrittore di distribuzione.

    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 4, Migrazione di progetti J2EE.

    Migrazione dei progetti Enterprise JavaBeans (da EJB 1.1 a EJB 2.1)

    La migrazione di un progetto EJB dal livello di specifica EJB 1.1 a EJB 2.1 viene descritta in questa sezione.

    La migrazione di un progetto EJB da EJB 1.1 a EJB 2.1 coinvolge la migrazione dei bean entity CMP (container-managed persistence):

    Non sono state apportate modifiche ai bean entity tra il livello di specifica J2EE 1.3 e J2EE 1.4. La migrazione dei bean entity CMP dal livello di specifica EJB 1.1 a EJB 2.1 viene eseguita nello stesso modo della migrazione di un bean entity CMP da EJB 1.1 a EJB 2.0. La migrazione dei bean entity gestiti dal contenitore dal livello di specifica EJB 1.1 a EJB 2.x richiede la seguente procedura:

    1. Conversione del progetto EJB da EJB 1.1 a EJB 2.x.
    2. Migrazione del codice EJB da EJB 1.1 a EJB 2.x.
    3. Migrazione di tutti i riferimenti EJB 1.1 definiti dall'utente nei riferimenti locali in EJB 2.x.

    Conversione di progetti da EJB 1.1 a EJB 2.x

    Un progetto EJB 1.1 può essere convertito in un progetto EJB 2.x utilizzando la procedura guidata Migrazione J2EE.

    In alternativa, se si desidera preservare il progetto EJB 1.1 originale, è possibile creare un nuovo progetto 2.x e importarvi il file JAR del progetto esistente (File -> Importa -> JAR EJB).

    Anche se questo è un progetto EJB 2.x, i bean entity CMP (container-managed persistence) EJB 1.1 esistenti (o importati) restano invariati. Pertanto, i bean entity CMP non vengono convertiti in EJB 2.

    La procedura guidata Migrazione J2EE consente di migrare i bean enterprise all'interno di un progetto EJB 2.x da 1.1 a 2.x. Se si desidera migrare i bean entity CMP 1.1 a 2.x, sarà necessario migrare tutti i bean contenuti nel progetto 2.x. Tuttavia, è possibile scegliere di aggiungere viste client locali ai bean 2.x migrati.

    Nota:
    Se sono presenti associazioni, verranno create associazioni EJB 2.x, ma le relative associazioni di ruoli non saranno più valide. Eseguendo il processo di convalida, si verificheranno degli errori. Per risolvere gli errori, aprire l'editor di associazione e salvare l'associazione. Le associazioni di ruoli saranno rimosse. A questo punto, eseguire nuovamente la convalida e riassociare i ruoli.

    Migrazione del codice da EJB 1.1 a EJB 2.x

    Per i progetti convertiti da EJB 1.1 a EJB 2.x, è necessario attenersi alla seguente procedura per migrare il codice esistente da EJB 1.1 a EJB 2.x.

    Nota:
    I bean EJB 2.x sono supportati solo in un progetto EJB 2.x (tuttavia, i progetti 2.x supportano anche i bean 1.1).

    1. Per qualsiasi bean CMP 1.1, sostituire ogni campo CMP con metodi getXXX e setXXX astratti. Anche la classe bean deve essere astratta.
    2. Per CMP, creare un metodo astratto getXXX e setXXX per la chiave primaria.
    3. Per il metodo finder CMP 1.1, creare un metodo EJBQL (EJB Query Language) per ogni metodo finder.
      Nota:
      EJB Query Language ha le seguenti limitazioni in Rational Application Developer V6.0:
      • Le query di EJB Query Language che comprendono EJB con chiavi composte di relazioni ad altri EJB verranno visualizzate come non valide e causeranno errori in fase di impiego.
      • Il supporto IBM EJB Query Language estende la specifica EJB 2.x in vari modi, tra cui la riduzione di alcune limitazioni, l'aggiunta di un supporto per più funzioni DB2 e così via. Se la portabilità attraverso vari database di fornitori o strumenti di distribuzione EJB costituisce un problema, allora l'attenzione deve essere rivolta a scrivere tutte le query EJB Query Language rigorosamente in base alle istruzioni descritte nel capitolo 11 della specifica EJB 2.x.
    4. Per qualsiasi finder CMP 1.1, restituire java.util.Collection anziché java.util.Enumeration.
    5. Per i bean CMP 1.1, modificare tutte le ricorrenze della stringa this.field = value con setField(value) in ejbCreate() ed in qualsiasi altro punto del codice.
    6. Aggiornare la gestione delle eccezioni (funzione rollback) per le eccezioni non appartenenti all'applicazione:
    7. Aggiornare la gestione delle eccezioni (funzione rollback) per le eccezioni dell'applicazione:
    8. Aggiornare le impostazioni CMP dei valori predefiniti specifici dell'applicazione in modo che siano all'interno di ejbCreate (non utilizzare variabili globali, poiché i contenitori EJB 1.1 impostano tutti i campi su valori predefiniti generici prima di richiamare ejbCreate che sovrascriverà tutte le precedenti impostazioni predefinite specifiche dell'applicazione).

    Migrazione dei riferimenti EJB per le relazioni EJB 1.1

    Durante la creazione delle relazioni EJB 1.1, sono stati creati riferimenti EJB alla vista Client remoto. Durante la migrazione dei progetti EJB 1.1 attraverso la procedura guidata Migrazione J2EE, tali riferimenti EJB remoti per le relazioni EJB 1.1 vengono rimossi e sostituiti con riferimenti EJB locali. I riferimenti locali per i riferimenti EJB definiti dall'utente devono essere ricreati manualmente.

    Nota:
    In EJB 2.x, le relazioni EJB possono essere create solo se la vista Client locale è stata definita per i bean e se i riferimenti EJB locali sono stati creati per le relazioni EJB 2.x.

    Per i riferimenti EJB definiti dall'utente, la migrazione non viene eseguita attraverso la procedura guidata Migrazione J2EE. Tuttavia, per impostare i riferimenti locali, procedere come segue:

    1. Eliminare i riferimenti remoti EJB nella pagina Riferimenti dell'editori del descrittore di distribuzione.
    2. Aggiungere un riferimento EJB locale nella pagina Riferimenti dell'editor del descrittore di distribuzione.

    Unione degli elementi del metodo durante la migrazione della struttura di progetti

    Durante la migrazione della struttura del progetto attraverso la procedura guidata Migrazione J2EE, gli elementi del metodo (che comprendono identità di protezione, transazione dei contenitori, autorizzazioni del metodo, tentativo di accesso e livelli di isolamento) dello stesso tipo per tutti i bean, vengono uniti per raggrupparli logicamente.

    Di seguito è riportato un esempio degli elementi del metodo prima e dopo la migrazione della struttura del progetto.

    L'esempio seguente mostra l'autorizzazione del metodo nella pagina di origine dell'editor del descrittore di distribuzione prima della migrazione della struttura del progetto.

    		<method-permission>
    			<role-name>rol1</role-name>
    			<role-name>rol2</role-name>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getEJBMetaData</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getHomeHandle</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-namae>remove</method-name>
    				<method-params>
    					<method-param>java.lang.Object</method-param>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>remove</method-name>
    				<method-params>
    					<method-param>javax.ejb.Handle</method-param>
    				</method-params>
    			</method>
    		</method-permission>
    		<method-permission>
    			<role-name>rol1</role-name>
    			<role-name>rol2</role-name>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Remote</method-intf>
    				<method-name>isIdentical</method-name>
    				<method-params>
    					<method-param>javax.ejb.EJBObject</method-param>
    				</method-params>
    			</method>
    		</method-permission>
    

    L'esempio seguente mostra l'autorizzazione del metodo nella pagina di origine dell'editor del descrittore di distribuzione dopo la migrazione della struttura del progetto.

    		<method-permission>
    			<role-name>rol1</role-name>
    			<role-name>rol2</role-name>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getEJBMetaData</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getHomeHandle</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>remove</method-name>
    				<method-params>
    					<method-param>>java.lang.Object</method-param>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>remove</method-name>
    				<method-params>
    					<method-param>javax.ejb.Handle</method-param>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Remote</method-intf>
    				<method-name>isIdentical</method-name>
    				<method-params>
    					<method-param>javax.ejb.EJBObject</method-param>
    				</method-params>
    			</method>
    		</method-permission>
    
    Nota:
    Se nella procedura guidata Migrazione J2EE, oltre alla migrazione della struttura del progetto è stata selezionata anche la migrazione dei bean da CMP 1.x a CMP 2.x, i tentativi di accesso e i livelli di isolamento vengono rimossi, mentre i rimanenti elementi verranno uniti durante la migrazione. I tentativi di accesso e il livello di isolamento vengono rimossi perché non vengono più considerati validi a causa delle modifiche apportate al modello di estensioni. Con il nuovo modello, sono disponibili i tentativi di accesso e il livello di isolamento definito nei tentativi di accesso, i tentativi di accesso di livello bean e di livello metodo. È preferibile utilizzare i tentativi di accesso di livello bean piuttosto che di livello metodo.

    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 Application Developer V6.0

    Alla procedura guidata Migrazione J2EE in Rational Application Developer V6.0 sono state apportate modifiche comuni alla migrazione di tutti i livelli di specifica J2EE.

    Migrazione facoltativa della struttura del progetto

    In WebSphere Studio da V5.1.x a V5.1.2, la migrazione della struttura del progetto viene eseguita contemporaneamente alla migrazione del livello di specifica J2EE. La migrazione della struttura del progetto non è facoltativa quando si migrano i livelli di specifica J2EE.

    Nella procedura guidata Migrazione J2EE in Rational Application Developer V6.0, l'opzione Migra la struttura del progetto è un'opzione facoltativa diversa dall'opzione Migra il livello di specifica J2EE del progetto. La migrazione del livello di specifica J2EE e la migrazione della struttura del progetto possono essere eseguite indipendentemente.

    Server di destinazione obbligatorio

    In Rational Application Developer V6.0, i progetti J2EE nuovi ed esistenti migrati a un livello di specifica J2EE superiore richiedono un server di destinazione impostato nel progetto. Il server di destinazione è il meccanismo predefinito per cui il percorso classi viene impostato in un progetto J2EE in V6.0. Per informazioni sull'impostazione di un server di destinazione e sull'utilizzo della procedura guidata Migrazione J2EE, fare riferimento alla guida in linea.


    Capitolo 5. Migrazione agli strumenti Portal in Rational Application Developer V6.0

    I progetti di Portal Toolkit V5.0.2.2 verranno migrati automaticamente agli strumenti del portale Rational Application Developer V6.0 migrando lo spazio di lavoro di Toolkit o caricando il progetto da un sistema SCM (source code management) o importando il progetto utilizzando la funzione Project Interchange. Se si desidera eseguire la migrazione dalle versioni precedenti di Portal Toolkit, è necessario esportare i progetti portlet nei file WAR e importare i file WAR negli strumenti Portal in Rational Application Developer V6.0.

    Prima di migrare le applicazioni del portale, è necessario installare la funzione relativa agli strumenti del portale di Rational Application Developer V6.0. Fare riferimento alla guida all'installazione.

    Nota:
    La compatibilità con le versioni precedenti dei progetti portlet non è supportata.

    La migrazione automatica è supportata solo per i progetti creati in Portal Toolkit V5.0.2.2 con WebSphere Studio V5.1.2. Per i dettagli sulla migrazione, fare riferimento a Capitolo 1, Migrazione da WebSphere Studio V5.1, 5.1.1 o 5.1.2.

    Se il progetto portlet è associato ad un progetto applicazione enterprise, sarà necessario impostare il server di destinazione appropriato sul progetto EAR. È possibile impostare il server di destinazione nella pagina Proprietà server (Proprietà -> Server).

    Durante la migrazione dei progetti Portal Toolkit V5.0.2.2, vengono effettuate altre modifiche:

    Se si desidera eseguire la migrazione dalle versioni precedenti di Portal Toolkit, è necessario migrare manualmente i progetti portlet agli strumenti Portal in Rational Application Developer V6.0, come segue:

    1. Esportare il progetto esistente in un file WAR: Nella versione precedente di Portal Toolkit, esportare ciascun progetto in un file WAR con i file di origine.
      1. Selezionare il progetto con il tasto destro del mouse e scegliere Esporta.
      2. Selezionare File WAR e Esporta file di origine, quindi fare clic su Fine.
    2. Importare il file WAR portlet:
      1. Negli strumenti Portal relativi a Rational Application Developer V6.0, creare un nuovo progetto portlet vuoto.
        1. Selezionare File -> Nuovo -> Progetto -> Portal -> Progetto Portlet o Progetto Portlet (JSR 168).
        2. Deselezionare l'opzione Crea portlet.
        3. Scegliere Mostra avanzate.
        4. Se si sta importando un portlet WebSphere Portal 4.2, selezionare 2.2 come versione servlet.
        5. Selezionare WebSphere Portal v5.0 come server di destinazione e scegliere Fine.
      2. Importare il file WAR nel nuovo progetto portlet vuoto.
        1. Selezionare Importa.
        2. Selezionare File WAR e specificare il file WAR esportato in precedenza (Esportazione di un progetto in un file WAR nella versione precedente).
        3. Selezionare il nuovo progetto portlet vuoto.
        4. Selezionare Sovrascrivi risorse esistenti senza avviso.
        5. Non selezionare Elimina progetto se sovrascritto.
    3. Eliminare il file TLD:

      Si consiglia di eliminare il file TLD portlet dal progetto, se esistente. Altrimenti, verrà visualizzato un messaggio di avviso alla successiva generazione del progetto. Se il file non viene eliminato, ciò potrebbe provocare un problema quando il progetto portlet viene distribuito su WebSphere Portal e il file TLD del portlet è diverso dal file presente sul server.

    4. Se si sta migrando un portlet WebSphere Portal 4.2, sarà necessario migrare il progetto portlet migrato a WebSphere Portal 5.x.

    Per informazioni sulla migrazione dei portlet WebSphere Portal da V4.2 a V5.x, fare riferimento a Migrazione dei portlet WebSphere Portal da V4.2 a V5.x.

    Per informazioni sulla migrazione delle risorse Faces in un progetto portlet, fare riferimento a Aggiornamento delle risorse di runtime Faces in un progetto portlet.


    Migrazione dei portlet WebSphere Portal da V4.2 a V5.x

    Rational Application Developer V6.0 non supporta lo sviluppo di portlet WebSphere Portal V4.2. È necessario migrare i progetti portlet di WebSphere Portal V4.2 a V5.x.

    Molti portlet scritti per WebSphere Portal V4.2 vengono eseguiti in WebSphere Portal V5.x senza alcuna modifica. Alcune API del portlet 4.2.x sono ora contrassegnate come obsolete, ma sono ancora disponibili su WebSphere Portal V5.x.

    Nota:
    I progetti applicazione portlet migrati non sono compatibili con le versioni precedenti.

    Per migrare le applicazioni portlet relative a WebSphere Portal da V4.2 a V5.x, procedere come segue:

    1. Migrare i progetti portlet da Portal V4.2 a Portal V5.x:
      1. Selezionare con il tasto destro del mouse il progetto applicazione portlet da migrare.
      2. Selezionare Proprietà -> API Portlet per aprire la pagina API Portlet.
      3. Selezionare WebSphere Portal Versione 5.x dall'elenco a discesa di livello API Portlet.
      4. Fare clic su OK, le modifiche di seguito riportate verranno effettuate automaticamente:
        • Il file TLD (tag library descriptor) relativo all'API portlet viene rimosso, se esiste.
        • Il livello Web viene modificato da 2.2 a 2.3.
        • Le voci del percorso classi specifiche del portlet vengono rimosse, quando il contenitore JRE WebSphere Portal e il contenitore di destinazione di runtime WebSphere Portal aggiungono le voci in modo dinamico.
    2. Se il progetto portlet è associato a un progetto applicazione enterprise, si consiglia di migrare il livello J2EE del progetto EAR a J2EE 1.3. Le applicazioni portlet progettate per WebSphere Portal V5.x devono essere conformi alle specifiche J2EE livello 1.3.
      Nota:
      Prima di migrare il progetto applicazione enterprise a J2EE 1.3, leggere Capitolo 4, Migrazione di progetti J2EE. Per informazioni sull'utilizzo della procedura guidata Migrazione J2EE, fare riferimento alla guida in linea.
      1. Se il progetto portlet migrato è associato solo al progetto applicazione enterprise, procedere come segue:
        1. Chiudere tutti gli editor del workbench.
        2. Fare clic con il tasto destro del mouse sul progetto applicazione enterprise con cui è associato il progetto portlet migrato.
        3. Selezionare Migra -> Procedura guidata Migrazione J2EE e fare clic su Avanti.
        4. Selezionare J2EE versione 1.3 e WebSphere Portal come server di destinazione.
        5. Scegliere Fine.
      2. Se altri progetti portlet sono associati al progetto applicazione enterprise, è necessario rimuovere il progetto portlet migrato e aggiungerlo ad un altro progetto applicazione enterprise.
        1. Rimuovere il modulo del progetto portlet migrato dal progetto applicazione enterprise.
          1. Espandere il progetto applicazione enterprise e selezionare il descrittore di distribuzione.
          2. Selezionare Apri con -> Editor del descrittore di distribuzione.
          3. Selezionare la scheda Modulo. Nella pagina Modulo dell'editor, selezionare il file WAR del progetto portlet migrato.
          4. Fare clic su Rimuovi.
          5. Selezionare File -> Salva per salvare le modifiche.
        2. Creare un nuovo progetto applicazione enterprise e aggiungervi il progetto portlet.
          1. Selezionare File -> Nuovo -> Progetto.
          2. Selezionare la casella di controllo Mostra tutte le procedure guidate.
          3. Espandere J2EE e selezionare Progetto applicazione Enterprise.
          4. Inserire i dati nel campo Nome del progetto, selezionare J2EE versione 1.3 e WebSphere Portal come server di destinazione, quindi fare clic su Avanti.
          5. Nella pagina Progetti modulo EAR, selezionare il progetto portlet migrato e fare clic su Fine.

    Il progetto portlet viene ora migrato a WebSphere Portal V5.x.


    Aggiornamento delle risorse di runtime Faces in un progetto portlet

    Le risorse di runtime JavaServer Faces runtime originariamente fornite con WebSphere Studio Application Developer V5.1.2 sono state aggiornate per Rational Application Developer V6.0.1. Se si desidera continuare lo sviluppo in progetti portlet creati con Portal Toolkit 5.0.2.2 per la versione precedente del prodotto, si consiglia di aggiornare le risorse di runtime Faces Client all'ultimo livello.

    In Rational Application Developer V6.0.1, gli aggiornamenti alle risorse di runtime Faces vengono effettuati automaticamente quando viene importato un progetto portlet o quando viene aperto uno spazio di lavoro che contiene risorse obsolete. Dopo aver importato un progetto portlet creato con Portal Toolkit 5.0.2.2 per WebSphere Studio Application Developer V5.1.x in Rational Application Developer V6.0.1, verrà richiesto di aggiornare le risorse di runtime Faces all'ultimo livello.

    Aggiornamento automatico delle risorse di runtime

    Per aggiornare le risorse di runtime Faces automaticamente per i progetti portlet, procedere come segue:

    1. Importare un progetto portlet contenente dati Faces da WebSphere Studio Application Developer V5.1.x. Viene aperta la finestra Migrazione progetto.
      Nota:
      Se la finestra Migrazione progetto non viene visualizzata, probabilmente l'impostazione di generazione automatica è disabilitata. In Esplora progetti, selezionare il progetto portlet con il tasto destro del mouse e scegliere Genera -> Progetto; il processo di rigenerazione di un progetto apre la finestra Migrazione progetto.
    2. Se si dispone di altri progetti portlet con contenuto Faces nello spazio di lavoro, selezionare l'opzione Applica questa scelta a tutti i progetti che devono essere aggiornati in modo che vengano aggiornati tutti i progetti portlet.
    3. Selezionare una delle seguenti opzioni:
    4. Per aggiornare le risorse di runtime Faces specifiche del portlet, jsf-portlet.jar e jsf-wp.jar, sarà necessario seguire le istruzioni per l'aggiornamento manuale riportate di seguito.
    Nota:
    Se sono state create JSP Faces contenenti componenti del client Faces, sarà necessario aggiornare separatamente le risorse di runtime dei componenti del client Faces all'ultimo livello. Consultare la sezione Aggiornamento delle risorse di runtime Faces Client in un progetto Web.

    Aggiornamento manuale delle risorse di runtime

    Per aggiornare le risorse di runtime Faces manualmente per i progetti portlet, procedere come segue:

    1. Importare il progetto portlet esistente con contenuto Faces nello spazio di lavoro di Rational Application Developer V6.0.1.
    2. Creare un nuovo progetto portlet denominato JSFP601 con l'opzione portlet Faces selezionata nella seconda pagina. Questo progetto verrà utilizzato solo come origine per le ultime risorse di runtime; può essere eliminato al termine dell'aggiornamento.
    3. In Esplora progetti, selezionare con il tasto destro del mouse il progetto JSFP601 e scegliere Proprietà dal menu.
    4. Scegliere Funzioni progetto Web e selezionare Aggiungi Faces Client Framework per il progetto Portlet, quindi scegliere OK.
    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:
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • jsf-portlet.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>
        		<variable-resolver>com.ibm.faces.application.WPPortletVariableResolver</variable-resolver>
        		<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
        	</application>
        
        Nota:
        Se il progetto portlet utilizza l'API JSR 168, specificare com.ibm.faces.application.PortletVariableResolver anziché com.ibm.faces.application.WPPortletVariableResolver.
      3. Per tutti i file JAR eliminati, copiare il file JAR dello stesso nome dalla directory WebContent/WEB-INF/lib del progetto JSFP601 e incollarlo nel progetto originale nello stesso percorso. Alcune configurazioni non richiedono che tutti questi file siano contenuti nel progetto; non copiare i file JAR non presenti nel progetto originale.
        • Se il progetto portlet utilizza l'API portlet IBM o un componente di collegamento Persona, copiare il file jsf-wp.jar nel progetto originale.
        • Se si copia il file odc-jsf.jar, copiare anche il file odc-jsf-portlet.jar.
      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>
        
    6. Eliminare il progetto portlet JSFP601.

    Capitolo 6. Modifiche negli ambienti di test di WebSphere

    In Rational Application Developer V6.0, gli ambienti di test WAS (WebSphere Application Server) inclusi con il prodotto sono stati modificati rispetto agli ambienti di test inclusi con le edizioni precedenti di WebSphere Studio Application Developer.

    Di seguito viene riportato un riepilogo delle modifiche agli ambienti di test WAS (WebSphere Application Server) in Rational Application Developer V6.0:

    Nella tabella di seguito riportata vengono illustrati i livelli degli ambienti di test WAS (WebSphere Application Server) con le diverse versioni di WebSphere Studio Application Developer e Rational Application Developer.

    Tabella 2. Ambienti di test WAS (WebSphere Application Server in WebSphere Studio Application Developer e Rational Application Developer


    WebSphere Application Server V4.x AEs WebSphere Application Server V5.x Base WebSphere Application Server Express 5.x WebSphere Application Server V5.x Portal WebSphere Application Server V6.0
    WebSphere Studio Application Developer V5.1 V4.0.6 V5.0.2 V5.0.2 N/D N/D
    WebSphere Studio Application Developer V5.1.1 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419, V5.1 V5.0.2 & V5.1 N/D N/D
    WebSphere Studio Application Developer V5.1.2 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419, V5.1.0.3 V5.0.2 & V5.1.0.3 V5.0.2.3 Base + WebSphere Portal V5.0.2.1 N/D
    Rational Application Developer V6.0 N/D V5.0.x, V5.1.1 V5.0.2 & V5.1.1 V5.0.2.6 Base + WebSphere Portal V5.0.2.2, V5.1.1 Base + WebSphere Portal 5.1 V6.0

    Copyright e informazioni particolari