Migrazione da WebSphere Studio "Classic" a IBM WebSphere
Studio Site Developer
Capitolo 1. Panoramica sulla Guida alla migrazione di WebSphere Application Server - Express
Capitolo 2. Migrazione del server di produzione
Capitolo 3. Migrazione da IBM WebSphere Studio Site Developer Versione 5.1
Capitolo 4. Migrazione da IBM WebSphere Studio Site Developer Versione 5 o Versione 5.0.1
Capitolo 5. Migrazione da IBM WebSphere Studio Site Developer Versione 4.0.x
Capitolo 6. Migrazione da WebSphere Studio "Classic" a IBM WebSphere Studio Site Developer
Capitolo 7. Migrazione da VisualAge per Java a IBM WebSphere Studio Site Developer
Capitolo 8. Migrazione dall'editor di composizione visiva di VisualAge per Java
Capitolo 10. Esempi di migrazione
Capitolo 11. Ulteriore documentazione
In questa versione di IBM(R) WebSphere(R)Application Server - Express Versione 5.1 , è possibile migrare il codice da:
WebSphere Application Server - Express 5.1 comprende WebSphere Application Server 5.1 e WebSphere Studio Site Developer 5.1.1. Il primo capitolo esamina la migrazione della funzioni server di WebSphere Application Server - Express. Gli altri capitoli della Guida alla migrazione riguardano la migrazione del codice da versioni diverse di WebSphere Studio Site Developer.
Nota importante relativa alla migrazione del server:
La migrazione della configurazione server è significativa solo se si gestisce il server mediante la Console di gestione, in genere in un ambiente di produzione. In questa modalità di funzionamento, la configurazione server e le applicazioni distribuite vengono memorizzate nella directory config del server. Il processo di migrazione consente di migrare i file di configurazione e applicazione. Se, d'altro canto, si utilizza WebSphere Studio Site Developer per configurare e distribuire applicazioni sul server remoto, non è necessario migrare i file di configurazione server. Questo perché i file di configurazione e applicazione vengono tutti mantenuti nello spazio di lavoro di Studio Site Developer. Lo spazio di lavoro verrà migrato da Studio Site Developer. E' possibile quindi definire una nuova istanza di un server WebSphere Application Server - Express 5.1 e continuare con la configurazione e la distribuzione delle applicazioni da Studio Site Developer.
La guida si articola nei seguenti capitoli:
Migrazione da WebSphere Studio "Classic" a IBM WebSphere
Studio Site Developer
Le informazioni relative all'utilizzo di WebSphere Application Server - Express sono reperibili nella guida introduttiva e nella guida in linea. Prima di installare WebSphere Application Server - Express, leggere la Guida all'installazione. Al termine dell'installazione di WebSphere Application Server - Express, leggere la Guida introduttiva e completare le esercitazioni in essa contenute. Le esercitazioni introdurranno l'utente all'utilizzo del workbench, allo sviluppo Java(TM) e ai servizi Web. Una volta completate le esercitazioni, consultare questa guida per migrare le risorse applicative a WebSphere Application Server - Express.
Questa guida è disponibile sia in formato HTML che Acrobat PDF, nella directory /readme. Le informazioni contenute nelle due versioni sono identiche. E' possibile visualizzare il file migrate.html in qualsiasi browser Web. Per visualizzare il file migrate.pdf, è necessario che il software Acrobat Reader, che è possibile scaricare dal sito www.adobe.com/products/acrobat/readstep2.html, sia installato sul computer.
Questa Guida alla migrazione si avvale delle convenzioni Windows(R). Ad esempio, "DirInstallazione_WS\" in Windows equivale a "DirInstallazione_WS/" in Linux.
Per futuri aggiornamenti a questa guida, visitare il sito www.ibm.com/websphere/developer/zones/studio/transition.html.
La migrazione è un'attività in cui l'utente trae vantaggio dal materiale esistente. Le attività e gli strumenti di migrazione consentono all'utente di aggiornare il prodotto e i relativi prerequisiti, di riutilizzare i componenti delle applicazioni esistenti, quando fattibile e di trasferire le configurazioni amministrative dalla vecchia versione alla versione corrente.
La migrazione dei prodotti WebSphere Application Server cerca di utilizzare l'ambiente e le applicazioni esistenti e di modificarle per renderle compatibili con la versione corrente del prodotto.
Le funzioni di migrazione del prodotto sono fornite dagli strumenti di migrazione di IBM WebSphere Application Server - Express, Versione 5.1. Gli strumenti di migrazione supportano la migrazione da:
La procedura guidata per l'installazione del prodotto individua le versioni precedenti di IBM WebSphere Application Server - Express e consente di eseguire gli strumenti di migrazione durante l'installazione della Versione 5.1. Per migrare da IBM WebSphere Application Server Versione 3.5, è necessario eseguire questi strumenti direttamente.
Redbook sulla migrazione
La pubblicazione Migrating to WebSphere V5: An End-to-End Migration Guide è disponibile al sito Web dei redbook all'indirizzo http://www.ibm.com/redbooks. Per individuare il redbook, ricercare il numero di documento SG24-6910-00. Il redbook fornisce informazioni più precise rispetto a questo articolo, incluse informazioni più dettagliate sulla pianificazione per la migrazione di applicazioni e strumenti e esempi di WebSphere Studio Application Developer.
Migrazione dalla versione 3.5: spostamento al modello J2EE
Gli utenti della V3.5.x che passano alla V5 si spostano su una piattaforma basata sulle specifiche J2EE. La tecnologia J2EE separa chiaramente lo sviluppo e la creazione di applicazioni dall'amministrazione, lo sviluppo e la gestione di applicazioni. La migrazione dalla V3.5 comporta modifiche nelle strutture dell'applicazione, nello sviluppo e nella distribuzione.
Gli strumenti di migrazione consentono di eseguire la transizione dalla Versione 3.5.x alla Versione 5 migrando le configurazioni dei sistemi e creando risorse J2EE, incluse le associazioni dei ruoli di sicurezza J2EE. Gli strumenti di migrazione creano applicazioni enterprise J2EE iniziali basate sulle configurazioni della Versione 3.5.x. Tuttavia, a causa dei cambiamenti significativi nelle strutture dell'applicazione, si consiglia, attraverso strumenti di sviluppo e distribuzione, di eseguire test accurati e di regolare le applicazioni migrate, per stabilire esattamente il funzionamento delle applicazioni nel nuovo ambiente.
Il modello J2EE consente di sviluppare le applicazioni indipendentemente dall'ambiente di sviluppo finale. La separazione di questa attività semplifica il processo di promozione di un'applicazione dallo sviluppo iniziale mediante produzione o lo spostamento di un'applicazione da un server all'altro. Lo scopo è quello di modificare solo i parametri di sviluppo dell'applicazione e non il codice dell'applicazione.
Prima di iniziare, controllare che una versione esistente di WebSphere Application Server sia installata sulla macchina su cui si prevede di installare il prodotto Versione 5.1. Se si dispone di una versione precedente, è necessario stabilire se si desidera copiare la configurazione e le applicazioni della versione precedente nella nuova versione, mediante migrazione. La migrazione non disinstalla la versione precedente. Il rilascio precedente è ancora funzionale. Se si esegue il rilascio precedente contemporaneamente all'installazione della Versione 5.1, le due versioni sono coesistenti. Per eseguire le due versioni contemporaneamente, è necessario configurare le porte in modo che non siano in conflitto. L'operazione di migrazione migra le definizioni di porta così come sono, per cui le definizioni di porta sono uguali su entrambe le versioni. WebSphere Application Server contiene strumenti di migrazione che forniscono tutte le funzioni di migrazione. E' possibile richiamare tali strumenti mediante la procedura guidata per l'installazione o manualmente in un momento successivo.
Nella panoramica, la migrazione da IBM WebSphere Application Server - Express V5.0.x alla V5.1 è quasi una routine. E' possibile utilizzare il programma di installazione per eseguire la migrazione e dover eseguire un'attività di regolazione post migrazione minima o inesistente. In alternativa, è possibile utilizzare gli strumenti di migrazione manualmente per salvare i dati di configurazione V5.0.0, V5.0.1 o V5.0.2, disinstallare la V5.0.0, V5.0.1 o V5.0.2, installare la V5.1 e utilizzare di nuovo gli strumenti di migrazione per ripristinare i dati di configurazione.
Nella panoramica, la migrazione da IBM WebSphere Application Server V3.5 a IBM WebSphere Application Server - Express V5.1 comporta cambiamenti significativi nelle strutture dell'applicazione, nello sviluppo e nella distribuzione. Gli strumenti di migrazione consentono di eseguire questa transizione migrando le configurazioni dei sistemi e creando risorse J2EE, inclusa l'associazione delle impostazioni di protezione precedenti ai ruoli di sicurezza J2EE. Queste associazioni di protezione consentono di accedere alle risorse migrate durante la transizione. Gli strumenti di migrazione creano applicazioni enterprise J2EE iniziali basate sulle configurazioni della V3.5.x. Tuttavia, a causa dei cambiamenti significativi nelle strutture dell'applicazione, si consiglia, attraverso strumenti di sviluppo e distribuzione, di eseguire test accurati e di regolare le applicazioni migrate.
La migrazione salva i file di seguito riportati nella directory backup.
Questa sezione introduce gli strumenti di migrazione forniti da WebSphere Application Server. Tutti gli strumenti di migrazione si trovano nella directory /migration del CD-ROM del prodotto. E' importante utilizzare gli strumenti di migrazione per la versione di Application Server che si desidera installare. Gli strumenti mutano col tempo. Gli strumenti presenti sul CD-ROM del prodotto forniscono le funzioni necessarie per la migrazione da un rilascio precedente di Application Server al rilascio presente sul CD-ROM del prodotto. Gli strumenti sul CD-ROM corrispondono al prodotto sul CD-ROM. Se si utilizzano strumenti di migrazione di un rilascio precedente di Application Server, è possibile rilevare problemi durante la migrazione.
Lo script WASPreUpgrade.sh (o WASPreUpgrade.bat) è uno strumento per la migrazione della configurazione e delle applicazioni di versioni o rilasci precedenti a Application Server - Express Versione 5.1.
Dopo l'installazione, il file dei comandi si trova nella sottodirectory AppServer/bin della directory principale di installazione. E' disponibile anche direttamente dal CD nella sottodirectory migration.
Sintassi
WASPreUpgrade backupDirectory currentWASDirectory
[adminNodeName]
[-nameServiceHost host_name [-nameServicePort port_number ]]
[-traceString trace_spec [-traceFile file_name ]]
Parametri
I primi due argomenti sono argomenti obbligatori e di posizione.
Gli argomenti supportati includono:
Log
Lo strumento WASPreUpgrade consente di visualizzare lo stato sullo schermo durante l'esecuzione. Consente inoltre di salvare un insieme più esteso di informazioni di log nella directory backup. E' possibile visualizzare il file WASPreUpgrade.log con un editor di testo.
Lo script WASPostUpgrade.sh (o WASPostUpgrade.bat) è uno strumento per la migrazione della configurazione e delle applicazioni di versioni o rilasci precedenti ad Application Server - Express Versione 5.1.
Il file dei comandi si trova nella sottodirectory AppServer/bin della directory principale di installazione.
Lo strumento WASPostUpgrade consente di installare tutte le applicazioni migrate nella directory AppServer/installedApps per l'installazione della Versione 5.1. Questo strumento include le applicazioni dalla directory di backup creata dallo strumento WASPreUpgrade. Lo strumento WASPreUpgrade copia le applicazioni dalla directory installedApps e da altre directory della versione o rilascio precedente.
Sintassi
WASPostUpgrade backupDirectory
[-serverName server_name]
[-webModuleAdditionalClasspath classpath]
[-documentRootLimit number]
[-substitute "key1=value1[;key2=value2;[...]]"]
[-portBlock port_starting_number]
[-backupConfig true | false]
[-replacePorts true | false]
[[-traceString trace_spec [-traceFile file_name]]
Parametri
Il primo argomento è obbligatorio. Gli argomenti supportati includono:
Nel file di dati XML di input, ciascuna chiave viene visualizzata come $key$ per la sostituzione. Questo argomento sostituisce qualsiasi ricorrenza di $NODE_NAME$ con admin_name e $APP_SERVER$ con default_server nel file XML di input.
Se la stringa di sostituzione contiene punti e virgole, utilizzare $semiColon$ per separare la stringa dal delimitatore ";". Sulle piattaforme UNIX, aggiungere un carattere di escape per ciascun segno di dollaro ($) presente nella stringa di sostituzione (ad esempio, \$semiColon\$).
Questo parametro è applicabile per le configurazioni salvate dalla Advanced Edition, Versione 3.5.x.
Log
Lo strumento WASPostUpgrade consente di visualizzare lo stato sullo schermo durante l'esecuzione. Consente inoltre di salvare un insieme più esteso di informazioni di log nella directory logs.E' possibile visualizzare il file WASPostUpgrade.log con un editor di testo.
Questa sezione descrive le modifiche che, durante la migrazione, coinvolgono una singola macchina, quali l'ambiente di sviluppo su una macchina autonoma.
Per informazioni dettagliate sui bean enterprise migrati, analizzare il file WASPostUpgrade.log. Il modello di programmazione J2EE specifica un'architettura per la creazione e lo sviluppo delle applicazioni. Poiché le applicazioni nella Versione 3.5.x non presentano la stessa architettura, lo strumento WASPostUpgrade ricrea le applicazioni. Tale strumento crea tutte le risorse Web e i bean enterprise migrati nelle applicazioni J2EE. Associa quindi tutte le applicazioni enterprise della Versione 3.5.x alle applicazioni J2EE con lo stesso nome, distribuite sullo stesso server.
Lo strumento WASPostUpgrade associa le risorse Web non incluse in un'applicazione enterprise ad un'applicazione J2EE predefinita, che include il nome del server. Lo strumento associa le applicazioni Web ai file WAR J2EE, unisce le risorse in un file EAR J2EE e lo distribuisce nella configurazione della Versione 5.
E' possibile utilizzare un file datasources.xml della Versione 3.5.x per potenziare le impostazioni di configurazione dell'origine dati. Nella Versione 3.5.x il file viene memorizzato nella directory properties. Gli strumenti di migrazione migrano un file datasources.xml esistente unendo le proprietà del file nella configurazione dell'origine dati e del driver JDBC.
Le voci dell'applicazione enterprise Versione 3.5.x sono facoltative, vengono molto spesso utilizzate per organizzare insiemi di oggetti per le definizioni di protezione. Il bean enterprise e le parti web dell'applicazione enterprise puntano alle rispettive voci in altre parti del file xml. Ciascuna applicazione enterprise viene elaborata per creare un'applicazione J2EE con lo stesso nome. Il bean enterprise e le voci delle applicazioni Web vengono utilizzati come puntatori per le definizioni dei bean enterprise e delle applicazioni Web. I dettagli di queste voci vengono quindi utilizzati per generare un'applicazione J2EE.
Per i file dei bean enterprise, la definizione file JAR viene utilizzata per ricercare i file JAR da ridistribuire e aggiungere all'applicazione J2EE. Le voci applicazione Web e directory principale documenti vengono utilizzate per ricercare le risorse utilizzate all'interno dell'applicazione Web (HTML, pagine JSP e così via). Questi file vengono copiati nel file WAR all'interno dell'applicazione J2EE. Le voci del percorso classi dell'applicazione Web vengono utilizzate per ricercare i servlet e i file JAR che vengono copiati nel file WAR all'interno dell'applicazione J2EE.
Le applicazioni enterprise vengono create durante la migrazione dalla Versione 3.5.x. Tali applicazioni vengono create come applicazioni enterprise compatibili con J2EE 1.2 e contengono i moduli di livello Servlet 2.2 e JSP 1.1. Ciò garantisce la massima compatibilità e consente l'interazione con le versioni precedenti di WebSphere Application Server.
Il modello di autorizzazione della protezione nella versione 3.5.x è basato sulla nozione di applicazione enterprise e gruppi di metodo. Il prodotto dell'applicazione enterprise e dei gruppi di metodo è un'autorizzazione WebSphere Application Server. La specifica J2EE include un modello di autorizzazione basato sui ruoli.
Per eseguire la conversione dal modello di autorizzazione WebSphere Application Server della versione 3.5.x al ruolo basato sul modello di autorizzazione della Versione 5, gli strumenti di migrazione creano un'associazione uno-a-uno da un'autorizzazione WebSphere Application Server e un nuovo ruolo presente in quell'applicazione. Quindi, per ciascuna applicazione enterprise e ciascun gruppo di metodo della Versione 3.5.x, gli strumenti di migrazione creano un ruolo nella Versione 5, contenuto nel descrittore di distribuzione dell'applicazione J2EE. I soggetti autorizzati per ciascun ruolo sono contenuti nella tabella delle autorizzazioni presente nel binding dell'applicazione J2EE.
La specifica J2EE include un modello di autorizzazione basato sui ruoli. WebSphere Application Server interpreta il ruolo come un insieme di autorizzazioni per accedere a una risorsa. Nel caso di un richiamo di un metodo bean enterprise, l'autorizzazione per accedere al metodo di un determinato bean viene specificata da un'autorizzazione del metodo. Questa autorizzazione del metodo è associata ad uno o più ruoli del descrittore di distribuzione presente nel file JAR del bean.
Nel caso di accesso alle risorse Web, l'autorizzazione ad accedere a un URI Web e a richiamare un metodo HTTP su quell'URI viene specificata nei termini di insieme di risorse Web e di vincoli di protezione nella specifica J2EE. Il descrittore di distribuzione del file WAR dell'applicazione Web contiene i vincoli di protezione e l'insieme di risorse Web.
La versione 5 esegue gli oggetti JSP 1.0 e 1.1 come oggetti JSP 1.2, che rappresenta l'unico livello supportato.
La versione 5 non supporta il redirector servlet delle versioni precedenti. Gli strumenti di migrazione ignorano questi oggetti.
Se la configurazione della versione 3.5.x definisce il servlet SimpleFileServlet, il servlet non viene migrato. Gli strumenti di migrazione impostano l'attributo FileServingEnabled nel file dei moduli Web ibm-web-ext.xmi in true.
Se la configurazione della versione 3.5 definisce il servlet InvokerServlet, il servlet non viene migrato. Gli strumenti di migrazione impostano l'attributo ServeServletsByClassnameEnabled nel file dei moduli Web ibm-web-ext.xml in true.
Se la configurazione della versione 3.5.x definisce il servlet DefaultErrorReporter, il servlet viene migrato nel file dei moduli Web web.xml. La migrazione utilizza il nuovo pacchetto per impostare il nome della classe.
Il tipo di trasporto predefinito del motore servlet Versione 3.5.x è OSE (Open Servlet Engine). Poiché la Versione 5 non supporta più il trasporto OSE, gli strumenti di migrazione associano questi trasporti ai trasporti HTTP, utilizzando le assegnazioni delle stesse porte. E' necessario aggiungere manualmente le entrate dell'alias VirtualHost per ciascuna porta.
E' possibile migrare le configurazioni amministrative manualmente o con la procedura guidata di installazione, come descritto da questa attività. Se si desidera eseguire la migrazione manuale, non selezionare la casella di controllo di migrazione nel pannello di migrazione della procedura guidata di installazione.
Se si utilizza una versione precedente di WebSphere Application Server, è possibile che l'amministratore di sistema abbia ottimizzato diverse impostazioni dell'applicazione e del server per l'ambiente utilizzato. E' importante disporre di una strategia per la migrazione di queste impostazioni con la massima efficienza e il minimo sforzo.
E' possibile eseguire la migrazione manuale incrementale richiamando gli strumenti di migrazione più volte, ogni volta specificando un file di configurazione diverso. Esistono vari motivi per cui sono necessari più file di configurazione. Qualunque sia il motivo, la migrazione di un unico file di configurazione alla volta consente di verificare le applicazioni in modo incrementale prima di continuare con il file di configurazione successivo.
Prima di utilizzare gli strumenti di migrazione, consultare il documento relativo alle note di rilascio della V5.x per informazioni sulle correzioni che devono essere applicate alle versioni precedenti. Applicando le correzioni a una versione precedente è possibile che le correzioni vengano applicate anche ai file che hanno un ruolo nella migrazione. Applicare tutte le correzioni per garantire la migrazione più efficace possibile di configurazioni e applicazioni.
La procedura manuale garantisce un'approccio alla migrazione più incrementale rispetto alla migrazione completa fornita dalla procedura guidata di installazione. IBM fornisce una serie di strumenti per la migrazione delle configurazioni amministrative al prodotto WebSphere Application Server - Express da qualsiasi edizione della V3.5.x o V5.0.x. Il processo di migrazione globale prevede il backup della configurazione corrente e dei file necessari con lo strumento di migrazione WASPreUpgrade, la disinstallazione del rilascio precedente, l'installazione del prodotto Versione 5 con l'opzione di migrazione automatizzata deselezionata e il ripristino della configurazione dal rilascio precedente con lo strumento di migrazione WASPostUpgrade.
Selezionare uno dei seguenti scenari di migrazione per informazioni su come eseguire la migrazione dei dati di configurazione su un nodo WebSphere Application Server di base:
E' possibile utilizzare gli strumenti di migrazione per migrare i dati di configurazione da WebSphere Application Server Versione 3.5 a WebSphere Application Server - Express Versione 5.1.
In genere, per eseguire l'aggiornamento dalla V3.5 alla V5.1 sulla stessa macchina, vengono utilizzati gli strumenti di migrazione WASPreUpgrade e WASPostUpgrade di WebSphere Application Server V5.1. Se lo scenario include la migrazione di una configurazione V3.5 da una macchina a WebSphere Application Server - Express V5.1 su un'altra macchina, utilizzare la procedura alternativa descritta nella sezione Migrazione della V3.5.x a una macchina V5.1 remota.
Questa sezione descrive l'utilizzo degli strumenti di migrazione V5.1 per migrare il seguente pacchetto:
Lo strumento WASPreUpgrade consente di salvare la configurazione della V3.5 esistente in una directory migration-specific-backup. Lo strumento WASPostUpgrade utilizza questa directory per aggiungere le impostazioni della vecchia configurazione al nuovo ambiente V5.1.
Fasi dell'attività
Su questo CD si trova la directory migration/bin. Questa directory contiene un ambiente particolare che è possibile utilizzare per eseguire lo strumento WASPreUpgrade senza installare la V5.1.
Salvare la configurazione nella directory migration-specific-backup:
WASPreUpgrade /usr/tmp/migration-specific-backup /usr/websphere/appserver yourNodeName
Verificare che il server amministrativo dell'ambiente esistente sia in esecuzione. Lo strumento WASPreUpgrade consente di visualizzare lo stato sullo schermo e di registrare i file nella directory migration-specific-backup. I nomi dei file di log ASCII iniziano con il testo WASPreUpgrade e includono una data/ora.
Lo strumento WASPreUpgrade consente di salvare tutti i file delle directory di seguito riportate nella configurazione della V3.5.x esistente nella directory di backup:
Lo strumento WASPreUpgrade consente di salvare i file selezionati dalla directory /bin della V3.5.x. Consente inoltre di esportare la configurazione del server di applicazioni esistente dal repository della V3.5.x. Lo strumento WASPreUpgrade richiama lo strumento XMLConfig per esportare il repository V3.5 esistente nel file websphere_backup.xml della directory migration-specific-backup.
Se si verificano errori durante l'esecuzione dello strumento WASPreUpgrade, è possibile che sia necessario applicare le correzioni all'installazione della V3.5 per completare correttamente la fase di esportazione. Per le ultime correzioni applicabili, fare riferimento alla pagina relativa al supporto IBM. Quando si visualizzano queste informazioni dall'InfoCenter, fare clic su Support per collegarsi alla pagina relativa al supporto IBM.
Non selezionare l'opzione di migrazione, se visualizzata.
Dopo ciascun utilizzo di WASPostUpgrade, verificare le impostazioni della porta V5 in due file:
Se la porta BOOTSTRAP_ADDRESS della versione precedente è 900, la migrazione associa questa porta a 7809. Se la porta BOOTSTRAP_ADDRESS della versione precedente non è 900, la migrazione associa il valore a server1 in una migrazione Advanced Edition o al nome server effettivo in una migrazione Advanced Single Server Edition.
L'elaborazione di WASPostUpgrade consente di aggiungere le porte Trasporto HTTP delle versioni precedenti al file server.xml della Versione 5. Ciò significa che server1 contiene assegnazioni porte Trasporto HTTP duplicate, per la coesistenza del server predefinito del pannello attuale e della versione precedente.
Lo strumento WASPostUpgrade esegue la migrazione delle informazioni di configurazione della V3.5.x create mediante lo strumento WASPreUpgrade all'installazione della V5.1. Poiché il prodotto V5.1 aderisce al modello di programmazione J2EE e il prodotto V3.5.x non aderisce a tale modello, è necessario applicare le modifiche significative della configurazione della V3.5.x all'installazione della V5.1.
Lo strumento WASPostUpgrade non esegue la migrazione degli esempi o dell'applicazione della console amministrativa, perché nella V5.1 esistono già degli esempi e un'applicazione della console amministrativa.
Lo strumento WASPostUpgrade registra informazioni dettagliate specifiche per ciascun bean enterprise distribuito nel file WASPostUpgrade.log.
La configurazione di WebSphere Application Server dopo la migrazione è un modo per verificare i risultati degli strumenti di migrazione. E' possibile anche utilizzare l'associazione Configurazione durante la migrazione per verificare i risultati della migrazione. La sezione comprende una descrizione dettagliata del modo in cui gli strumenti di migrazione migrano gli oggetti e degli elementi che è necessario verificare.
E' possibile utilizzare gli strumenti di migrazione per eseguire una migrazione manuale tra due macchine.
In genere, per eseguire l'aggiornamento dalla V3.5 alla V5.1 sulla stessa macchina, vengono utilizzati gli strumenti di migrazione WASPreUpgrade e WASPostUpgrade di WebSphere Application Server - Express.
Tuttavia, esistono alcuni scenari in cui è necessario migrare la configurazione della V3.5 presente su una macchina alla V5.1 su una macchina diversa. Uno di questi scenari prevede l'installazione di nuove macchine per l'ambiente V5.1 e la necessità di migrare la configurazione della V3.5 esistente su altre macchine.
Questa sezione descrive l'utilizzo degli strumenti di migrazione V5.1 per migrare il seguente pacchetto:
Lo strumento WASPreUpgrade consente di salvare la configurazione della V3.5 esistente in una directory migration-specific-backup. Lo strumento WASPostUpgrade utilizza questa directory per aggiungere le impostazioni della vecchia configurazione nel nuovo ambiente V5.1.
Fasi dell'attività
Su questo CD si trova la directory migration/bin. Questa directory contiene un ambiente particolare che è possibile utilizzare per eseguire lo strumento WASPreUpgrade senza installare la V5.1.
Salvare la configurazione nella directory migration-specific-backup della macchina V3.5.
WASPreUpgrade /opt/tmp/migration-specific-backup /opt/websphere/appserver adminNodeName
Verificare che il server amministrativo dell'ambiente esistente sia in esecuzione.
Lo strumento WASPreUpgrade consente di visualizzare lo stato sullo schermo e di registrare i file nella directory /migration-specific-backup. I nomi dei file di log ASCII iniziano con il testo WASPreUpgrade e includono una data/ora.
Lo strumento WASPreUpgrade consente di salvare i file selezionati dalla directory /bin della V3.5.x. Consente inoltre di esportare la configurazione del server di applicazioni esistente dal repository della V3.5.x. Lo strumento WASPreUpgrade richiama lo strumento XMLConfig per esportare il repository V3.5 esistente nel file websphere_backup.xml della directory migration-specific-backup.
Se si verificano errori durante l'esecuzione dello strumento WASPreUpgrade, è possibile che sia necessario applicare le correzioni all'installazione della V3.5 per completare correttamente la fase di esportazione. Per le ultime correzioni applicabili, fare riferimento alla pagina relativa al supporto IBM. Quando si visualizzano queste informazioni dall'InfoCenter, fare clic su Support per collegarsi alla pagina relativa al supporto IBM.
Utilizzare ftp, memoria condivisa o altri tipi di meccanismi per copiare il file sulla nuova macchina.
Eseguire i seguenti passaggi sulla macchina con WebSphere Application Server - Express V5.1.
Il file viene copiato perché nella fase successiva il file originale verrà modificato.
Apportare le modifiche nel file:
Se si desidera utilizzare per la macchina V5.1 lo stesso nome nodo utilizzato per la configurazione V3.5 originale, non modificare il nome. Altrimenti, è necessario modificare tutte le ricorrenze del nome nodo V3.5 nel nome nodo utilizzato per WebSphere Application Server V5.1. Il nome nodo è presente in molte stanze XML del file. Se non vengono modificate tutte le ricorrenze, la migrazione dei dati risulterà incompleta.
Il file di configurazione si riferisce ai percorsi di molte stanze XML del file. Aggiornare qualsiasi riferimento a un file esterno alla struttura della directory V3.5 nella directory equivalente sulla nuova macchina, anche se è necessario creare una directory equivalente. La configurazione di un ambiente corrispondente significa che potrebbe essere necessario copiare la directory originale sulla macchina V5.1. Oppure, potrebbe essere necessario dover installare il software appropriato.
E' necessario correggere le specifiche di percorso se differiscono da quelle presenti sulla macchina su cui è in esecuzione la V5.1. Ad esempio, se si sta passando dalla V3.5 su una piattaforma Windows alla V5.1 su una piattaforma Linux, modificare qualsiasi percorso specifico di Windows nel file di configurazione per utilizzare lo stile del percorso Linux. Modificare "c:\mystuff\somepath" in "/opt/mystuff/somepath".
E' necessario modificare ID utenti e password se non sono identici a quelli in uso sulla macchina V5.1.
Per modificare una password codificata in una password di testo, modificare <password>{xor}LCoxayht</password> in <password>mypassword</password>.
La configurazione può fare riferimento a altri prodotti software o configurazioni che non sono presenti sulla nuova macchina. Ad esempio, sulla vecchia macchina può essere presente un database. La configurazione della V5.1 deve, se possibile, puntare ancora al database presente sulla vecchia macchina. Modificare l'origine dati in modo che punti al database sulla macchina V3.5.
Utilizzare lo strumento WASPostUpgrade, presente nella directory AppServer/bin della directory principale di installazione V5.1 per aggiungere la configurazione V3.5 alla configurazione V5.1.
WASPostUpgrade /opt/tmp/migration-specific-backup
Lo strumento WASPostUpgrade registra informazioni dettagliate specifiche per ciascun bean enterprise distribuito nel file /migration-specific-backup/WASPostUpgrade.log.
E' possibile utilizzare il programma di installazione V5.1 per eseguire la migrazione da WebSphere Application Server - Express V5.0.x alla V5.1.
Fasi dell'attività:
Utilizzare lo script stopServer.sh (o stopServer.bat) presente nella directory AppServer/bin della directory principale di installazione:
stopServer.sh server1
E' possibile migrare un nodo V5.0.x senza arrestarlo. Tuttavia, per migrare la configurazione, non è necessario che il nodo sia in esecuzione. Gli strumenti di migrazione possono richiamare tutti i dati di configurazione anche se il nodo è stato arrestato. E' necessario arrestare il nodo prima di avviare il nodo V5.1 che si desidera installare. E' quindi possibile arrestare il nodo ora.
Selezionare l'opzione di migrazione, quando visualizzata.
Utilizzare lo strumento First Steps quando visualizzato alla fine dell'installazione del prodotto oppure eseguire il test di verifica dell'installazione, se lo strumento First Steps non viene visualizzato per qualche motivo.
Se si desidera, è possibile disinstallare il server V5.0.x.
E' possibile utilizzare gli strumenti di migrazione per eseguire una migrazione tra due macchine.
Prima di cominciare
In genere, per eseguire l'aggiornamento dalla V5.0.x alla V5.1 sulla stessa macchina, vengono utilizzati gli strumenti di migrazione WASPreUpgrade e WASPostUpgrade di WebSphere Application Server V5.1.
Tuttavia, esistono alcuni scenari in cui è necessario migrare la configurazione della V5.0.x presente su una macchina alla V5.1 su una macchina diversa. Uno di questi scenari prevede l'installazione di nuove macchine per l'ambiente V5.1 e la necessità di migrare la configurazione della V5.0.x esistente su altre macchine.
Questa attività descrive come utilizzare gli strumenti di migrazione V5.1 per eseguire la migrazione.
Lo strumento WASPreUpgrade consente di salvare la configurazione della V5.0.x esistente in una directory migration-specific-backup. Lo strumento WASPostUpgrade utilizza questa directory per aggiungere le impostazioni della vecchia configurazione nel nuovo ambiente V5.1.
Fasi dell'attività
Su questo CD si trova la directory migration/bin. Questa directory contiene un ambiente particolare che è possibile utilizzare per eseguire lo strumento WASPreUpgrade senza installare la V5.1.
Salvare la configurazione nella directory migration-specific-backup della macchina V5.0.x.
WASPreUpgrade /opt/tmp/migration-specific-backup /opt/websphere/appserver
Lo strumento WASPreUpgrade consente di visualizzare lo stato sullo schermo e di registrare i file nella directory /migration-specific-backup. I nomi dei file di log ASCII iniziano con il testo "WASPreUpgrade" e includono una data/ora.
Utilizzare ftp, memoria condivisa o altri tipi di meccanismi per copiare il file sulla nuova macchina.
Utilizzare lo strumento WASPostUpgrade, presente nella directory AppServer/bin della directory principale di installazione V5.1 per aggiungere la configurazione V5.0.x alla configurazione V5.1.
WASPostUpgrade /opt/tmp/migration-specific-backup
Lo strumento WASPostUpgrade registra informazioni dettagliate specifiche per ciascun bean enterprise distribuito nel file /migration-specific-backup/WASPostUpgrade.log.
Apportare le seguenti modifiche:
E' necessario modificare ID utenti e password se non sono identici a quelli in uso sulla macchina V5.0.x.
La configurazione può fare riferimento a altri prodotti software o configurazioni che non sono presenti sulla nuova macchina. Ad esempio, sulla vecchia macchina può essere presente un database. Modificare l'origine dati in modo che punti al database sulla vecchia macchina.
E' possibile migrare una versione precedente di WebSphere Application Server Versione 3.5.x o Versione 5.0.x in esecuzione su un sistema operativo non supportato dalla Versione 5.1.
Fasi dell'attività
Esistono due opzioni. E' possibile eseguire il comando dalla directory migration\bin (o migration/bin) nella platform_root del CD-ROM della Versione 5.1. In alternativa, è possibile copiare i file presenti nella directory del CD-ROM su una directory creata sul disco fisso.
Identificare la Versione 3.5.x o 5.0.x e identificare una directory di backup in cui il comando memorizza i file di configurazione e le applicazioni di migrazione della versione precedente. Per la sintassi del comando, fare riferimento alla sezione relativa a WASPreUpgrade.
Identificare la directory di backup e il percorso dei file di configurazione.
Unità_CD:\WASPreUpgrade backupDirectory filepath\WebSphere\AppServer yourNodeName
Se funziona, andare al passo 4. Se non funziona per qualche motivo, eseguire i passi da 2B a 2F.
Modificare le variabili di seguito riportate:
Identificare la directory di backup e il percorso dei file di configurazione.
yourMigrationDirectory\WASPreUpgrade backupDirectory filepath\WebSphere\AppServer yourNodeName
Se possibile, mantenere lo stesso nome e le stesse password del vecchio sistema. Inserire tutti i file di database relativi alle applicazioni che si sta migrando nello stesso percorso del vecchio sistema. In generale, mantenere tutti i vecchi percorsi. Non installare, tuttavia, la Versione 5.1 nella stessa directory della versione precedente. Se vengono modificati percorsi e nomi, è possibile modificare i file di configurazione XML per riflettere le modifiche. Apportare tali modifiche prima di eseguire il comando WASPostUpgrade.
Specificare la directory di backup (e qualsiasi nome di file di configurazione non standard presente nella directory) creata dal comando WASPreUpgrade. Per la sintassi corretta del comando, fare riferimento alla sezione relativa a WASPostUpgrade.
install_root\bin\WASPostUpgrade WAS_HOME\migration
Nel capitolo sono trattati i seguenti argomenti di migrazione:
In IBM WebSphere Studio Site Developer Versione 5.1.1 è stata aggiunta una nuova funzione Destinazione server. Questa funzione è disabilitata per impostazione predefinita ed è necessario abilitarla nella pagina Preferenze J2EE selezionando Finestra > Preferenze > J2EE. I dettagli sul funzionamento della funzione Destinazione server sono reperibili nella documentazione del prodotto IBM WebSphere Studio Site Developer. Quando la funzione viene abilitata, è possibile definire come destinazione un determinato server di applicazioni. Questa funzione è stata implementata per supportare JDK 1.4, vale a dire il JRE per WebSphere Application Server Versione 5.1 fornito con IBM WebSphere Studio Site Developer Versione 5.1.1. I progetti J2EE che traggono vantaggio dal supporto Destinazione server non sono compatibili con le versioni precedenti di IBM WebSphere Studio Site Developer, quindi non possono essere condivisi con gli utenti che utilizzano le versioni precedenti di IBM WebSphere Studio Site Developer (ad esempio, IBM WebSphere Studio Site Developer Versione 5.1, IBM WebSphere Studio Site Developer Versione 5.0.1). Con questa funzione abilitata, IBM WebSphere Studio Site Developer fornisce la compatibilità con le versioni precedenti. La funzione è descritta nella sezione "Compatibilità con le versioni precedenti con il supporto Destinazione server abilitato". Il motivo di questa incompatibilità sta nel fatto che la funzione Destinazione server modifica il file .classpath di un progetto J2EE e le entrate del nuovo file .classpath non possono essere riconosciute dalle versioni precedenti di WebSphere Application Server - Express.
Con il supporto Destinazione server abilitato, è possibile fare in modo che i progetti J2EE con destinazione server non utilizzino il supporto Destinazione server, se si modifica il server di destinazione in un'opzione Nessun server di destinazione specificato disponibile nella finestra di dialogo Modifica server di destinazione. La finestra di dialogo Modifica server di destinazione viene avviata dal menu di scelta rapida (Server di destinazione > Modifica) di un progetto J2EE, nella vista Selezione risorse o Prospettiva J2EE. Il server di destinazione può essere anche modificato in Nessun server di destinazione specificato dalla pagina Proprietà J2EE (Proprietà > J2EE) per EAR, EJB, client di applicazioni e progetti connettore. Per un progetto Web, l'impostazione del server di destinazione si trova nella pagina Proprietà Web (Proprietà > WEB). I dettagli sul funzionamento della funzione di modifica di Destinazione server sono reperibili nella documentazione di IBM WebSphere Studio Site Developer. Quando viene utilizzata l'opzione Nessun server di destinazione specificato, il file .classpath viene convertito in uno stile compatibile con le versioni precedenti di IBM WebSphere Studio Site Developer e il file .server viene rimosso dal progetto.
A causa di una modifica in JDK 1.4, l'utente deve specificare un pacchetto Java quando utilizza le procedure guidate Pagine Web database e Pagine Web dei bean Java per generare pagine che vengano eseguite su IBM WebSphere Studio Site Developer Versione 5.1.1. Questo problema si verifica se il modello Bean di visualizzazione viene utilizzato per la procedura guidata Pagine Web dei bean Java o Bean Java di accesso al database IBM - Modello dei dettagli principali. Si riferisce inoltre ai progetti contenenti pagine e file .java precedentemente generati con queste procedure guidate, per i quali non è stato specificato alcun pacchetto durante la creazione. Per il codice precedentemente generato, spostare i file .java in un pacchetto. Quindi aggiornare i file .jsp, aggiornare le istruzioni di importazione e le informazioni sulle classi. Nel file web.xml del progetto, aggiornare la voce servlet-class..
Nel capitolo sono trattati i seguenti argomenti di migrazione:
IBM WebSphere Studio Site Developer Versione 5.1.1 è basato sul nuovo Eclipse, WebSphere Studio Workbench (WSWB) 2.1.2. Tra le versioni 2.1.2 e 2.0.3 o 2.0.2 esistono alcune differenze. Per informazioni dettagliate su tali differenze, consultare il file readme situato nella directory DirInstallazione_WS\eclipse\readme (dove DirInstallazione_WS è il percorso in cui è stato installato IBM WebSphere Studio Site Developer.
IBM WebSphere Studio Site Developer Versione 5.0 è basato su Eclipse WSWB 2.0.2, mentre IBM WebSphere Studio Site Developer Versione 5.0.1 è basato su Eclipse WSWB 2.0.3. Tra versioni 2.0.2 e 2.0.3 non esistono grosse differenze. Il rilascio IBM WebSphere Studio Site Developer Versione 5.0.1 è un Update Manager fixpack, installato su IBM WebSphere Studio Site Developer Versione 5.0.
Quando IBM WebSphere Studio Site Developer Versione 5.1.1 viene avviato per la prima volta utilizzando uno spazio di lavoro esistente di IBM WebSphere Studio Site Developer Versione 5.0, viene visualizzata una finestra di dialogo in cui viene illustrato un modo per eseguire la migrazione dalla Versione 5.0. Fare clic su OK per migrare lo spazio di lavoro Versione 5.0 oppure fare clic su Annulla per arrestare IBM WebSphere Studio Site Developer.
Una volta migrato lo spazio di lavoro, è possibile utilizzare ancora lo spazio di lavoro con la Versione 5.0, in quanto i metadati delle funzioni del nuovo progetto vengono ignorati e possono essere letti dalla Versione 5.0. Non è possibile apportare alcuna modifica nella Versione 5.0 ai progetti dello spazio di lavoro che influiscono sui metadati o sovrascrivere i metadati delle funzioni del nuovo progetto.
La migrazione dei progetti Java dalla Versione 5 o Versione 5.0.1 è molto semplice e quasi del tutto automatica. Dopo aver caricato i progetti nello spazio di lavoro della Versione 5.1.1, non viene apportata alcuna modifica ai metadati dei file .classpath o .project a meno che non venga utilizzata una delle nuove funzioni della Versione 5.1.1.
Prestare particolare attenzione se un progetto del repository team viene caricato e manipolato da sviluppatori che utilizzano IBM WebSphere Studio Site Developer Versione 5 IBM WebSphere Studio Site Developer Versione 5.1.1. Il problema generale consiste nel fatto che l'esistenza, il contenuto e l'interpretazione dei file di metadati negli spazi di lavoro, potrebbero essere specifici di una particolare versione di una funzione o di un plug-in, quindi essere diversi in altre versioni. La compatibilità tra gli spazi di lavoro garantisce un corretto funzionamento solo quando tutti gli sviluppatori aggiornano i rispettivi spazi di lavoro di IBM WebSphere Studio Site Developer in una sola fase. In questo caso non ci saranno problemi con i metadati condivisi. Tuttavia, se alcuni sviluppatori utilizzano IBM WebSphere Studio Site Developer Versione 5.1.1 ed altri IBM WebSphere Studio Site Developer Versione 5, tale condizione non può essere garantita. Questa sezione suggerisce come comportarsi in questa situazione.
La modalità tipica di errore è conosciuta all'utente di IBM WebSphere Studio Site Developer Versione 5.1.1. I metadati della Versione 5.1.1 andranno persi quando un utente della Versione 5 salva le modifiche ed esegue il commit dei file di metadati aggiornati nel repository. Di seguito sono riportate alcune delle situazioni che potrebbero presentarsi:
Di seguito è riportato un elenco di suggerimenti a cui attenersi quando i progetti sono condivisi tra utenti di IBM WebSphere Studio Site Developer Versione 5.1.1 e Versione 5 o Versione 5.0.1:
Questo supporto è stato aggiunto in IBM WebSphere Studio Site Developer Versione 5.1.1. Le informazioni sulle risorse collegate sono registrate nel file .project.
Suggerimento: Non utilizzare. Per maggiore sicurezza, disabilitare le risorse collegate nella pagina delle preferenze Workbench > Risorse collegate.
Le informazioni sui programmi di generazione di strumenti esterni sono registrate nel file .project. Il formato delle informazioni è diverso nella Versione 5 e nella Versione 5.1.1. I programmi di generazione creati o modificati nella Versione 5.1.1 utilizzano il nuovo formato, che non sarà compreso da uno spazio di lavoro della Versione 5. I programmi di generazione creati nella Versione 5 utilizzano il vecchio formato e possono essere utilizzati nella Versione 5.1.1.
Suggerimento: Creare o modificare sempre i programmi di generazione di strumenti esterni negli spazi di lavoro della Versione 5.
Questo supporto è stato aggiunto. Le relative informazioni sono registrate nel file .classpath.
Suggerimento: Non specificare alcun modello di esclusione. Per maggiore sicurezza, disabilitare i modelli di esclusione nella pagina delle preferenze Java > Compiler > Percorso di generazione.
Questo supporto è stato aggiunto. Le relative informazioni sono registrate nel file .classpath.
Suggerimento: Non specificare alcuna cartella ad eccezione della cartella di output predefinita (relativa a tutto il progetto). Per maggiore sicurezza, disabilitare i percorsi di output multipli nella pagina delle preferenze Java > Compiler > Percorso di generazione.
Collegando un file ZIP di origine a una libreria JAR nel percorso di generazione Java, il prefisso per percorso principale di origine verrà assegnato automaticamente. Questa impostazione è stata modificata rispetto alla Versione 5, dove poteva essere impostato esplicitamente attraverso l'interfaccia utente e registrato nel file .classpath. Di conseguenza, un progetto Java creato in uno spazio di lavoro 5.1.1 potrebbe non individuare l'origine collegata.
Per specificare il percorso principale del collegamento origine, utilizzare la Versione 5. La Versione 5.1.1 fornisce ulteriori funzioni per le operazioni con i collegamenti origine. E' possibile indicare una cartella invece di un file JAR o ZIP come collegamento, ed è possibile collegare un'origine a una cartella di file di classe; questa funzionalità non è disponibile nella Versione 5 (dove le informazioni relative alla Versione 5.1.1 verranno ignorate).
I PDE che utilizzano i contenitori del percorso classi sono stati aggiunti. Tali contenitori vengono registrati nel file .classpath. Se utilizzati, lo spazio di lavoro della Versione 5 conterrà voci di percorso classi non risolte, quindi la maggior parte delle funzioni Java (comprese la compilazione, la ricerca, l'esecuzione e il debug) non otterranno i risultati previsti.
Suggerimento: Assicurarsi che l'impostazione nella pagina delle preferenze Sviluppo plug-in > Controllo percorso di generazione Java relativa all'utilizzo dei contenitori del percorso classi sia disabilitata prima di creare nuovi progetti di plug-in (o frammenti)
I nomi delle cartelle sono Java Source e Web Content. I nomi predefiniti per le cartelle dei nuovi progetti Web possono essere configurati nella pagina delle preferenze (Finestra > Preferenze > Strumenti Web > Nuovo progetto).I nomi predefiniti sono ora JavaSource e WebContent. Questi nomi verranno utilizzati solo per i nuovi progetti Web. I progetti Web creati nelle versioni precedenti a questo rilascio continueranno a funzionare utilizzando i vecchi nomi. La stessa situazione si verifica per i progetti Web statici.
Se si desidera modificare i nomi delle cartelle di origine per i progetti delle versioni 4.0.x e 5.0 nella Versione 5.1.1, utilizzare l'azione del menu di scelta rapida Rinomina nella vista Selezione. Il comando Rinomina consente di ridenominare le cartelle e di correggere il percorso di generazione Java dei progetti Web delle versioni 4.0.x e 5.0.x.
Per la cartella JavaSource, l'azione del menu di scelta rapida Rinomina è disponibile sia nella vista Selezione progetti che nella vista Pacchetti. Per la cartella WebContent, l'azione del menu di scelta rapida Rinomina è disponibile sia nella vista Selezione risorse che nella vista Selezione progetti.
Se un progetto Web di una versione precedente a questo rilascio viene salvato in un repository SCM e successivamente caricato in questo rilascio, manterrà la vecchia struttura con le cartelle source e webApplication. E' possibile generare correttamente qualsiasi struttura.
Il runtime degli strumenti Struts è passato dalla Versione 1.1 Beta 2 della Versione 5 alla Versione 1.1. In IBM WebSphere Studio Site Developer Versione 5 GA (General Availability), quando si crea un progetto Web, è possibile aggiungervi il supporto Struts. E' possibile scegliere Struts 1.0.2 o Struts 1.1 Beta 2. In IBM WebSphere Studio Site Developer Versione 5.1.1, la seconda scelta è stata sostituita con Struts 1.1. Se in IBM WebSphere Studio Site Developer Versione 5, è preferibile convertirli in Struts 1.1, anche se non è obbligatorio in quanto Struts 1.1 Beta 2 è ancora supportato. Se si desidera convertire i progetti Web Struts 1.1 Beta 2 in Struts 1.1, procedere come segue:
Tutte le informazioni fornite possono essere utilizzate anche se si desidera spostare un progetto Web Struts 1.1 Beta 3 in IBM WebSphere Studio Site Developer Versione 5.0.1 in Struts 1.1.
Agli strumenti dei servizi Web sono stati aggiunti due nuovi protocolli di runtime di IBM WebSphere Application Server Versione 5.0.2 che possono essere eseguiti solo su WebSphere Application Server Versione 5.0.2. Non è necessario eseguire alcuna migrazione in quanto IBM WebSphere Studio Site Developer Versione 5.1.1 e WebSphere Application Server Versione 5.0.2 supportano i vecchi e i nuovi protocolli di runtime. IBM WebSphere Studio Site Developer genera e distribuisce tre protocolli di runtime delle risorse dei servizi Web: il vecchio protocollo "IBM SOAP" che viene eseguito su WebSphere Application Server Versione 4.x e Versione 5.x; il nuovo protocollo "IBM WebSphere 5.0.2 runtime" che può essere eseguito solo su WebSphere Application Server Versione 5.0.2; e il nuovo protocollo "Apache Axis 1.0" che può essere eseguito solo su WebSphere Application Server Versione 5.0.2.
Gli utenti possono riutilizzare i progetti della Versione 5 e i file EAR e WAR relativi ai servizi Web nella Versione 5.1.1. Per convertire i servizi e client Web nel nuovo protocollo di runtime IBM WebSphere 5.0.2 e poter utilizzare i nuovi standard JSR 101, 109, WS-I e WS-Security, sarà necessario eseguire una rigenerazione utilizzando la procedura guidata Servizi Web. L'explorer dei servizi Web continuerà automaticamente a leggere i preferiti dell'utente anche se i file di dati fisici saranno stati spostati automaticamente in una nuova posizione.
Durante la migrazione di uno spazio di lavoro dalla Versione 5, è possibile ricevere il messaggio di errore "Problemi durante il ripristino del workbench". Il messaggio viene visualizzato se la prospettiva Creazione profili viene aperta durante la migrazione e se le viste Heap o Statistica istanza sono visibili nella prospettiva Creazione profili. Questo succede perché la vista Heap e la vista Statistica istanza che esistevano nella Versione 5 sono state eliminate. Il messaggio viene visualizzato anche se la prospettiva Creazione profili viene aperta nello spazio di lavoro durante la migrazione. E' possibile ignorare il messaggio facendo clic su OK.
Per utilizzare un modello personalizzato creato nella Versione 5, è necessario caricare il modello, riconnettersi al database e salvarlo. Ricaricando nuovamente il modello personalizzato salvato, la connessione viene verificata.
Le risorse J2EE 1.2 create in questo rilascio potrebbero risultare non leggibili per IBM WebSphere Studio Site Developer Versione 4.0.3 ed essere eseguite solo negli ambienti di test della Versione 4.0.3. Dal momento che la procedura guidata Modello non era inclusa nella Versione 4.0.3, non viene conservata alcuna compatibilità con questa versione.
Le applicazioni modello generate in questo rilascio possono essere eseguite solo nella Versione 5 se nelle preferenze del progetto Web, la cartella di origine Java viene denominata "Java Source" e la cartella del contenuto Web "Web Content".
Questo capitolo descrive la migrazione dalla Versione 4.0.x alla Versione 5 di IBM WebSphere Studio Site Developer.
Per migrare i progetti da IBM WebSphere Studio Site Developer Versione 4.0.x alla Versione 5, utilizzare uno dei due metodi descritti di seguito:
Si osservi che la migrazione dalla Versione 4 alla Versione 5 non modifica automaticamente il livello J2EE del progetto, poiché la Versione 5 può ancora eseguire funzioni di generazione e distribuzione in WebSphere Application Server, Versione 4. Tutti i tipi di progetto J2EE, inclusi i progetti Web, possono essere migrati utilizzando la procedura guidata Migrazione J2EE disponibile in IBM WebSphere Studio Site Developer. Per accedere alla procedura guidata Migrazione J2EE, selezionare un progetto di tipo J2EE con il tasto destro del mouse e scegliere Migra > Procedura guidata Migrazione J2EE.
Di seguito è riportato un elenco parziale dei miglioramenti apportati alla Versione 4.0.x:
In WebSphere InfoCenter [www.ibm.com/software/webservers/appserv/doc/v40/aes/infocenter/index.html] sono disponibili le seguenti informazioni:
La pubblicazione Migrating to WebSphere V5.0 An End-to-End Migration Guide è una buona fonte di informazioni sulla migrazione dalle versioni 3.5 e 4.0 alla Versione 5 [www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246910.pdf].
Dalla pagina di download di WebSphere Application Server [www14.software.ibm.com/webapp/download/product.jsp?s=p&id=TDUN-49EVRT&type=s&dt=DIAGNOSTIC+TOOL] è possibile scaricare strumenti per la conversione dell'applicazione:
Se i progetti presentano dipendenze circolari, la Versione 5 riporta un errore di generazione. In questo caso, è possibile scegliere Finestra > Preferenze > Java > Compilatore, selezionare la scheda Percorso di generazione e deselezionare la casella di controllo Interrompi generazione in caso di errori nel percorso di generazione. Tenere presente che in questo modo la creazione non verrà più interrotta ma verranno ancora visualizzati gli errori di 'dipendenza circolare' nella vita Attività (anche quando l'opzione di creazione viene eseguita correttamente). In questo caso, è possibile modificare questi errori in avvisi selezionando la scheda Altro e modificando le preferenze nel menu a discesa Dipendenze circolari.
In IBM WebSphere Studio Site Developer Versione 5, sono presenti modifiche interne alla struttura del progetto rispetto alla Versione 4.0.3. Un file J2EE 1.2 Web WAR, nella Versione 5, quando esportato con l'origine Java, consentirà di importare in IBM WebSphere Studio Site Developer Versione 4 e il nome della cartella del codice di origine verrà convertito automaticamente nel nome corretto, consentendo di eseguire la generazione senza errori. Il progetto Web potrà essere eseguito correttamente in WebSphere Application Server Versione 4, così come quando il progetto della Versione 4 viene importato nella Versione 5, perché il nome della cartella del codice di origine è stato convertito automaticamente nel nome corretto. Per ulteriori informazioni sulla modifiche ai nomi delle cartelle, consultare la sezione "Strutture dei progetti Web di IBM WebSphere Studio Site Developer"
La struttura di un progetto Web interno in IBM WebSphere Studio Site Developer Versione 5 differisce da quella di IBM WebSphere Studio Site Developer Versione 4.0.x. La differenza non riguarda soltanto J2EE 1.2 rispetto a J2EE 1.3, quanto piuttosto una modifica di utilizzo dello strumento.
Nella Versione 4, i progetti Web erano per impostazione predefinita progetti Web dinamici e venivano visualizzati nella vista selezione con una cartella Source e una cartella webApplication. Un progetto Web dinamico creato nella Versione 5, verrà visualizzato con la cartella Java Source in sostituzione della cartella Source e la cartella Web Content in sostituzione della cartella webApplication.
Tuttavia, se un progetto Web della Versione 4 viene salvato in un repository SCM e poi ricaricato nella Versione 5, conserverà la vecchia struttura con le cartelle Source e webApplication.Entrambe le strutture saranno create correttamente nella Versione 5.
Nella Versione 5 è possibile creare progetti Web statici e dinamici.
I progetti Web statici contengono solo risorse statiche come HTML, Java Script, immagini, testo e così via, e nessun contenuto dinamico. I progetti Web statici possono essere eseguiti utilizzando un server Web HTTP tradizionale e non necessitano Web Application Server.
I progetti Web dinamici contengono oltre alle risorse statiche, risorse J2EE dinamiche come servlet, JSP, filtri e metadati associati. Durante la creazione dei progetti Web dinamici, è possibile includere fogli di stile sovrapposti e librerie di tag JSP, in modo da cominciare lo sviluppo con un insieme di risorse di progetto più fornito. I progetti Web dinamici sono sempre incorporati in un progetto Enterprise Application e possono essere eseguiti solo su server di applicazioni Web.
Questo è il metodo consigliato per spostare spazi di lavoro dalla Versione 4.0.x a IBM WebSphere Studio Site Developer Versione 5. E' il solo metodo che consente di migrare tutte le informazioni, incluse quelle sul percorso di generazione del progetto.
Suggerimento: nella Versione 4, la directory dello spazio di lavoro si trovava per impostazione predefinita nella directory di installazione. Nella Versione 5, la directory predefinita workspace si trova nella directory Documenti. Per sostituire il percorso in cui è salvato il lavoro, utilizzare l'opzione -data del comando all'avvio del workbench.
Per ClearCase: utilizzare uno spazio di lavoro vuoto della Versione 5, quindi per ogni progetto da caricare, selezionare File > Importa > Progetto ClearCase WebSphere Studio 4.x esistente nello spazio di lavoro.
Considerazioni post migrazione:
Impossibile creare il progetto perché coinvolto in un ciclo o per la presenza di problemi nel percorso classi. Cartella di origine richiesta mancante: /MyHomePageExample403/source.
I file con estensione dell'applicazione IBM EAR Versione 4 e i file di configurazione server contenevano riferimenti a percorsi assoluti. Una volta migrati nella Versione 5, sarà necessario aprirli con l'editor corrispondente (che consentirà di modificare automaticamente i vecchi riferimenti assoluti in nuovi riferimenti).
Il file delle estensioni IBM contiene percorsi assoluti obsoleti. Tale file può essere corretto automaticamente e dovrebbe essere salvato. Continuando i percorsi verranno rimossi dal file e tale operazione dovrà essere eseguita una volta sola. Procedere con la correzione automatica?
Esistono altri fornitori SCM che forniscono plug-in SCM per IBM WebSphere Studio Site Developer. E' possibile consultare l'elenco dei fornitori all'indirizzo www.ibm.com/software/ad/studioappdev/partners/scm.html. Tutti i distributori SCM che hanno fornito plug-in della Versione 4, come parte della certificazione Ready for IBM WebSphere Studio Software [www.developer.ibm.com/websphere/ready.html], hanno garantito che i passaggi precedenti la migrazione (salvare dalla Versione 4 in un repository SCM, caricare dal repository nella Versione 5) funzionano anche nei rispettivi sistemi.
Questo approccio è supportato solo in parte e causerà una migrazione incompleta. Andranno perse tutte le impostazioni di interfaccia utente, di debug e la maggior parte delle preferenze. Saranno conservati con sicurezza soltanto i nomi dei progetti, i file di origine e il percorso di generazione Java (percorso classi). Utilizzare questo approccio soltanto se non si utilizza un sistema supportato e se è importante conservare le informazioni relative al percorso di generazione del progetto, che vengono perse durante l'importazione di progetti esportati dalla Versione 4. E' possibile utilizzare lo spazio di lavoro della Versione 4.0.x esistente procedendo nel seguente modo:
Le istruzioni post migrazione descritte nella sezione Eliminazione dei riferimenti di percorso assoluti EAR e di configurazione server post migrazione vengono applicate anche in questa sezione.
Se si tenta di eseguire una migrazione aprendo uno spazio di lavoro nella Versione 4 con IBM WebSphere Studio Site Developer Versione 5, potrebbero verificarsi i seguenti problemi:
Per ripristinare la variabile del percorso classi JRE_LIB in un percorso corretto, eseguire i seguenti passaggi. Eseguire l'operazione anche se il valore sembra corretto alla prima apertura della finestra Preferenze.
Senza eseguire questa operazione, il valore di JRE_LIB potrebbe non essere corretto e provocare molti errori di generazione in un file Java.
Come controllo generale, verificare i valori di tutte le altri variabili del percorso classi.
Il supporto team è stato modificato in maniera significativa tra Eclipse 1.0 e 2.0. E' stato modificato, inoltre, il metodo di condivisione di progetti con il repository.
Per impostazione predefinita, i progetti sono creati nella directory dello spazio di lavoro. Se è stata sostituita l'impostazione predefinita per creare progetti altrove, è necessario aprire tutti i progetti prima di chiudere il workbench. Mediante questa operazione, il file .project dei relativi progetti verrà scritto nel percorso corretto. Se un progetto chiuso, la cui directory si trova all'esterno dello spazio di lavoro, non viene aperto, verrà creato un progetto che maschera quello reale con un unico file .project all'interno di esso.
Sarà necessario rimuovere tutti gli eventuali punti di interruzione JSP presenti e reimpostarli all'interno dello spazio di lavoro migrato nella Versione 5.
Per migrare i dati relazionali dai progetti 4.0.3 di IBM WebSphere Studio Site Developer:
Le risorse dei dati relazionali verranno ripristinate.
Se è stato importato un file di servizi Web da 4.0.x, è possibile ricevere i seguenti messaggi di errore:
Errore: la parte 'result' presenta un valore 'anyElement' non valido definito per il tipo. Le dichiarazioni di tipo devono riferirsi a valori validi definiti in uno schema. Errore: la parte 'return' presenta un valore 'findPatientResult' non valido definito per l'elemento. Le dichiarazioni di elemento devono riferirsi a valori validi definiti in uno schema. Errore: la parte 'response' presenta un valore 'findPatientResponse' non valido definito per l'elemento. Le dichiarazioni di elemento devono riferirsi a valori validi definiti in uno schema.
La soluzione è:
Per accedere alla procedura guidata Migrazione J2EE nella Versione 5, procedere come segue:
Questo capitolo descrive come migrare da WebSphere Studio 4.0 (in entrambe le versioni Advanced e Professional) a IBM WebSphere Studio Site Developer . La migrazione da WebSphere Studio "Classic" Versione 4.0 a IBM WebSphere Studio Site Developer Versione 5.0 comporta i seguenti passaggi:
Le funzioni di pubblicazione avanzata (associazione di file a fasi di pubblicazione) e Page Detailer (analisi di pagine Web) di WebSphere Studio "Classic" non sono disponibili in IBM WebSphere Studio Site Developer . Anche altre funzioni del pacchetto di supporti CD della Versione 4.0.x non sono più disponibili. Ad esempio, la funzione Page Detailer per l'analisi delle pagine web, il dispositivo HotMedia(R), l'editor Voice XML (spostato in WebSphere Everyplace(TM) Toolkit e Portal Toolkit) e DataBaseWizard per le periferiche più diffuse.
Considerare le seguenti limitazioni prima di trasferire i propri dati WebSphere Studio:
Durante il processo di migrazione descritto di seguito, WebSphere Studio crea un file JAR che contiene tutti i file di progetto, pubblicabili e di origine, per un singolo server. Tutti i file visibili nella vista Pubblicazione per il server predefinito saranno compressi nel file JAR. E' possibile quindi importare il file JAR in IBM WebSphere Studio Site Developer.
Durante la migrazione di progetti esistenti, tutte le informazioni sulle fasi e sulla pubblicazione del progetto verranno perse. Se per la fase sono disponibili più server, vengono conservati solo i file pubblicati nel server predefinito. Quindi, a scopo di migrazione, verrà creata una nuova fase in cui sia disponibile un solo server.
Se sono presenti più server nella fase corrente, creare una nuova fase denominata Migrazione con un solo server, effettuando queste operazioni:
Il nome del file descrittore di configurazione Web predefinito è serverName_web.xml, localhost_web.xml per questo scenario. A meno che non venga specificato un percorso diverso, il file .xml viene salvato nella directory WEB-INF.
A questo punto è possibile verificare la propria applicazione. Per eseguire il controllo sul server di verifica predefinito, procedere come segue:
Per verificare la propria applicazione su altri ambienti runtime del server, fare riferimento alla guida in linea relativa alla funzione Strumenti server.
Questo capitolo fornisce istruzioni sulle modalità di migrazione da VisualAge(R) per Java Professional Edition o VisualAge per Java Enterprise Edition a IBM WebSphere Studio Site Developer.
Instantiations, Inc., un Business Partner IBM, distribuisce un
prodotto, denominato CodePro Studio, che incrementa la produttività di
VisualAge per Java e di WebSphere Application Server - Express e include
funzioni di migrazione e coesistenza. Per aiutare gli utenti di
VisualAge per Java nella migrazione, Instantiations offre una funzione di
esportazione gratuita, ad utilizzo illimitato di VisualAge per Java a IBM
WebSphere Studio Site Developer come parte della copia di valutazione limitata
di CodePro Studio. E' possibile scaricare la copia di valutazione
da www.instantiations.com/vaj-migrate.
Per ulteriori informazioni sul supporto avanzato di migrazione e coesistenza
di Instantiations, incluse le funzioni di importazione/esportazione
bidirezionale dei file, creazione delle serie di importazioni ed esportazioni,
sincronizzazione progetto e automazione attività, fare riferimento a
Instantiations, Inc. www.instantiations.com/codepro/ws.
Di seguito viene riportato un elenco parziale delle differenze rispetto a VisualAge per Java:
I seguenti passaggi illustrano come eseguire la migrazione da VisualAge per Java. I dettagli sull'esecuzione di queste attività vengono forniti di seguito:
La migrazione in blocco di versioni di progetti e risorse dal repository di VisualAge per Java non è supportata. E' possibile migrare soltanto i progetti e le risorse presenti nello spazio di lavoro di VisualAge per Java. Se si desidera migrare la copia della versione di un progetto o una risorsa in IBM WebSphere Studio Site Developer, è necessario trasportarla nello spazio di lavoro di VisualAge per Java.
Esportare i progetti in un file JAR seguendo questi passaggi:
Avviare IBM WebSphere Studio Site Developer, quindi creare i progetti. Di seguito viene riportata una serie di indicazioni generali sulla migrazione che consentono di determinare in quale tipo di progetto IBM WebSphere Studio Site Developer importare i file:
Se la propria applicazione utilizza servlet, è necessario definire le associazioni servlet-URL nel file web.xml. Procedere come segue:
E' necessario registrare le seguenti impostazioni di VisualAge per Java ed impostarle in IBM WebSphere Studio Site Developer:
Percorso classi di progetto
In VisualAge per Java, il percorso classi del progetto è impostato nelle pagine Risorse della finestra Opzioni (Finestra > Opzioni > Risorse). Al termine della migrazione dei progetti in IBM WebSphere Studio Site Developer , è possibile impostare il percorso classi del progetto nella corrispondente finestra Proprietà (selezionare il progetto con il tasto destro del mouse e scegliere Proprietà > Percorso di generazione Java. Fare clic sulla scheda Librerie.) E' inoltre possibile impostare le variabili del percorso classi nella finestra Preferenze (Finestra > Preferenze > Java > Variabili di percorso classi.)
Associazioni di risorse
Se si imposta un'associazione tra un tipo file e un eseguibile, è possibile aprire un file situato all'esterno del workbench dall'interno di quest'ultimo.
In VisualAge per Java, le associazioni di risorse sono impostate nella finestra Opzioni (Finestra > Opzioni > Risorse > Associazioni di risorse). Una volta eseguita la migrazione dei file di risorse in IBM WebSphere Studio Site Developer, è possibile impostare le associazioni di risorse mediante la finestra Preferenze (Finestra > Preferenze > Workbench > Associazioni file).
Programma di formattazione codice
In VisualAge per Java, le opzioni di formattazione del codice sono impostate nella pagina Programma di formattazione della finestra Opzioni (Finestra > Opzioni > Codifica > Programma di formattazione). Una volta eseguita la migrazione del codice in IBM WebSphere Studio Site Developer, è possibile impostare la formattazione del codice nella la finestra Preferenze (Finestra > Preferenze > Java > Programma di formattazione codice).
Configurazione WTE
In VisualAge per Java, le impostazioni runtime per WebSphere Unit Test Environment e WebSphere Application Server si trovano in vari file di proprietà nella seguente directory: DirInstallazioneVisualAge\ide\project_resources\IBM WebSphere Test Environment\properties, dove DirInstallazioneVisualAge indica la directory di installazione del prodotto.
Se, ad esempio, è stata abilitata la riscrittura dell'URL nel file delle proprietà session.xml, modificando la proprietà su true, come riportato di seguito, <url-rewriting-enabled>true</url-rewriting-enabled> è possibile configurare questa proprietà nell'ambiente di test di IBM WebSphere Studio Site Developer Versione 4.0. Nella prospettiva Server, aprire la vista Configurazione server, selezionare il server che si desidera utilizzare con il tasto destro del mouse e scegliere clic su Apri. Fare clic sulla scheda Web e selezionare la casella di controllo Attiva riscrittura URL).
File Java e file di risorse di progetto
Il file di proprietà default.servlet_engine contiene la directory di contesto <root-uri> delle applicazioni Web di VisualAge per Java. Durante la creazione di un progetto Web in IBM WebSphere Studio Site Developer, la finestra di dialogo Crea progetto Web contiene il campo Directory principale relativo a questi dati.
Le impostazioni dell'applicazione Web in file quali DirInstallazioneVisualAge\ide\project_resources\IBM WebSphere Test Environment\hosts\default_host\default_app\servlets\default_app.webapp personalizzati dall'utente, dovrebbero essere migrate nel file progetto_WebWeb Content\WEB-INF\web.xml in IBM WebSphere Studio Site Developer. Ad esempio, se sono stati modificati nomi e percorsi di servlet nel file default_app.webapp, è necessario effettuare le corrispondenti modifiche anche nel file web.xml dell'utente.
Se l'applicazione è un progetto Java, per verificarla è sufficiente utilizzare il normale supporto per progetti Java Esegui o Debug di IBM WebSphere Studio Site Developer .
Se l'applicazione utilizza WebSphere Application Server , eseguire il controllo utilizzando WebSphere Application Server integrato. Per questa operazione è richiesta la creazione e l'avvio di un server di test predefinito. Per un progetto Web, selezionare la pagina HTML principale con il tasto destro del mouse, e scegliere Esegui su server in modo da avviare il browser web.
Per informazioni sulla verifica di altri tipi di progetti, fare riferimento alla guida in linea.
Se si utilizza WebSphere Application Server come ambiente runtime, distribuire la propria applicazione utilizzando la funzione Server Tools di IBM WebSphere Studio Site Developer.
I progetti di IBM WebSphere Studio Site Developer (e le relative impostazioni) possono essere condivisi tra più sviluppatori. A tal scopo, salvare un progetto nel server SCM di IBM WebSphere Studio Site Developer ed estrarlo, quindi, presso un altro membro del team in IBM WebSphere Studio Site Developer.
Per informazioni sul supporto team in IBM WebSphere Studio Site Developer Versione 4.0, visitare la pagina www.ibm.com/websphere/developer/library/techarticles/0108_karasiuk/0108_karasiuk.html
Le informazioni relative al supporto team in IBM WebSphere Studio Site Developer sono reperibili anche nella Guida all'installazione e nella guida in linea.
Questo capitolo fornisce istruzioni sulle modalità di migrazione di applicazioni create nell'editor di composizione visiva di VisualAge per Java all'editor visivo per Java all'interno di WebSphere Application Server - Express.
Questo passo è facoltativo, ma fortemente consigliato (specialmente se le proprie applicazioni utilizzano delle connessioni) per i seguenti motivi.
Per salvare le informazioni sui metadati prima della migrazione:
Le classi sono pronte per l'importazione in WebSphere Application Server - Express. Fare riferimento alla sezione Capitolo 7, "Migrazione da VisualAge per Java a IBM WebSphere Studio Site Developer". Una volta che i programmi di origine del precedente editor di composizione visiva sono stati importati in WebSphere Application Server - Express, è possibile conservarli nell'editor visivo per Java.
Nel capitolo sono trattati i seguenti argomenti di migrazione:
Per informazioni dettagliate, vedere l'articolo (in inglese) J2EE Class Loading Demystified all'indirizzo www.ibm.com/websphere/developer/library/techarticles/0112_deboer/deboer.html) (moduli J2EE e percorso classi) e quello relativo allo sviluppo di JAR di utilità J2EE (www.ibm.com/websphere/developer/library/techarticles/0112_deboer/deboer2.html) (JAR Java in moduli J2EE). Questi ultimi forniscono eccellenti background e suggerimenti tecnici.
Il metodo consigliato per utilizzare un JAR di terzi all'interno di un progetto Web è quello di importarlo (come file JAR) in una cartella di libreria del progetto Web. Questo rappresenta l'unico sistema definito da J2EE per utilizzare un file JAR ed assicura all'utente di non dover effettuare alcuna modifica durante la distribuzione in un altro server.
Per utilizzare un file JAR esterno in un singolo progetto Web, procedere come segue. Se si desidera utilizzare il file JAR in più progetti Web, attenersi alle istruzioni descritte nella sezione "Metodo consigliato per l'utilizzo di JAR di altri produttori con più progetti Web" .
Il metodo consigliato per utilizzare un file JAR di altri produttori con due o più progetti Web consiste nell'importarlo (come file JAR) nel progetto EAR. Questo rappresenta l'unico sistema definito da J2EE per utilizzare un file JAR ed assicura all'utente di non dover effettuare alcuna modifica durante la distribuzione in un altro server.
Per utilizzare un file JAR esterno con più progetti Web, attenersi alle seguenti istruzioni. Se è necessario utilizzare il file JAR soltanto in un progetto Web, seguire i passaggi riportati nella sezione precedente.
E' anche possibile lasciare il file JAR all'esterno di WebSphere Application Server - Express e aggiungerlo al percorso di generazione Java e al percorso classi dell'istanza server. Questa operazione non è consigliata, poiché l'applicazione non sarà facilmente trasportabile. Quando si passa a un server differente, sarà sempre necessario aggiornare il percorso classi del server. Inoltre, sarà necessario verificare che i file di classe non siano in conflitto con altre versioni di file di classe simili già presenti sul percorso classi del server (e richiesti dal server o da altre sue applicazioni). Se, in ogni caso, si decide di utilizzare questo approccio, seguire i seguenti passaggi:
L'importante funzione di generazione automatica di WebSphere Application Server - Express può rallentare le prestazioni durante generazioni complesse per più progetti. Esistono varie modalità per controllare queste generazioni automatiche (file dipendenti, progetti attivi e inattivi, progetti in formato JAR od origine), ma si tratta di opzioni alquanto complicate. Un articolo spiega le opzioni utilizzabili e le modalità di ottimizzazione della prestazione della generazione. Fare riferimento all'articolo in WebSphere Developer Domain "Optimizing Multi-Project Builds Using dependent Project JARs in WebSphere Studio Application Developer" (www.ibm.com/websphere/developer/library/techarticles/0204_searle/searle.html).
Per automatizzare le generazioni di produzione, è possibile utilizzare Ant con WebSphere Application Server - Express. Un articolo in più paragrafi spiega:
Vedere l'articolo in WebSphere Developer Domain "Utilizzo Ant con WebSphere Studio Application Developer" (in inglese) (www.ibm.com/websphere/developer/library/techarticles/0203_searle/searle1.html).
Questo capitolo contiene esempi utili per familiarizzare con la migrazione da VisualAge per Java e WebSphere Studio "Classic" a WebSphere Application Server - Express IBM WebSphere Studio Site Developer.
Descrizione
Si tratta dell'esempio FindTheLeapYears fornito con VisualAge per Java, Versione 4.0. Le relative informazioni sono reperibili nella Guida in linea di VisualAge per Java (Esempi > Ambiente di sviluppo JSP/Servlet).
Panoramica sulla migrazione
Per migrare l'esempio da VisualAge per Java a IBM WebSphere Studio Site Developer verranno effettuati i passaggi riportati di seguito. Questi passaggi verranno illustrati in maggior dettaglio:
Importare i file di origine Java nella directory di origine del progetto LeapYear seguendo questi passi:
Importare i file di risorse nel progetto LeapYear nella directory WebContent, attenendosi alle seguenti istruzioni:
Ora è necessario apportare le modifiche all'applicazione a causa di alcune differenze nella struttura origine/applicazione:
A questo punto l'esempio è stato migrato in IBM WebSphere Studio Site Developer. Resta da creare un progetto server IBM WebSphere Studio Site Developer e verificare l'esempio nell'ambiente di test WebSphere.
Ora è necessario specificare il proprio progetto EAR nella configurazione server:
Descrizione
Per questo esempio, è necessario utilizzare WebSphere Studio "Classic", Versione 4.0.x.
L'esempio che si sta per utilizzare è YourCo. Per accedere a questo esempio, aprire la Guida in linea (? > WebSphere Studio 4.0 > Indice della guida > Utilizzo degli esempi > Panoramica). Per caricare l'esempio, seguire le istruzioni riportate in Apertura degli esempi Studio (per WebSphere Application Server 4.0) e caricare YourCo.war.
Prima di cominciare
Passaggi di migrazione
Per migrare questo esempio da WebSphere Studio "Classic" a IBM WebSphere Studio Site Developer, è necessario attenersi alla procedura di seguito riportata. Successivamente, ciascuna fase viene descritta in dettaglio.
(Facoltativo) Normalmente, per una migrazione è creata una nuova fase ma ai fini di questo esempio sarà utilizzata la fase Test inclusa in WebSphere Studio "Classic". L'utilizzo della fase Test consente di evitare la modifica manuale di molte associazioni servlet al punto 8.
Per informazioni sulle modalità di creazione di una nuova fase di migrazione, consultare il capitolo "Migrazione da WebSphere Studio "Classic" a IBM WebSphere Studio Site Developer".
a. com.ibm.db richiede databeans.jar, b. com.ibm.webtools.runtime richiede webtlsrn.jar, c. com.ibm.ejs.ns.jndi richiede ns.jar, d. com.ibm.webshpere.advanced.cm.factory richiede cm.jar, e. com.ibm.ejs.models.base.extensions.webappext.ServletExtensions richiede ws-base-extensions.jar
Per effettuare la correzione, è necessario modificare il percorso di generazione Java per il progetto Web.
A questo punto l'esempio è stato migrato in IBM WebSphere Studio Site Developer. Resta da creare un progetto server IBM WebSphere Studio Site Developer e verificare l'esempio nell'ambiente di test WebSphere.
Ora è necessario specificare il proprio progetto EAR nella configurazione server:
Informazioni aggiornate sulla migrazione e altri argomenti sono disponibili presso www.ibm.com/websphere/developer/zones/studio/transition.html
Le seguenti pubblicazioni e pagine Web forniscono informazioni generali utili per l'utilizzo di WebSphere Application Server - Express:
Ulteriori informazioni di interesse:
Nota relativa alle Limitazioni previste per gli Utenti del Governo degli Stati Uniti - L'uso, la duplicazione o la divulgazione sono limitati dal GSA ADP Schedule Contract con la IBM Corp.
Queste informazioni sono state sviluppate per i prodotti e i servizi offerti negli Stati Uniti. E' possibile che negli altri paesi l'IBM non offra i prodotti, i servizi o le funzioni illustrati in questa documentazione. Consultare il rappresentante locale IBM per informazioni sui prodotti e sui servizi attualmente disponibili nel proprio paese. Qualsiasi riferimento relativo a prodotti, programmi o servizi IBM non implica che solo quei prodotti, programmi o servizi IBM possano essere utilizzati. In sostituzione a quelli forniti dall'IBM, possono essere usati programmi, prodotti o servizi funzionalmente equivalenti che non comportino violazione dei diritti di proprietà intellettuale o di altri diritti dell'IBM. E' comunque responsabilità dell'utente valutare e verificare la possibilità di utilizzare altri prodotti, programmi o servizi non IBM.
L'IBM può essere titolare di brevetti o domande di brevetto in corso relativi a quanto trattato nella presente documentazione. La fornitura di tale documentazione non implica la concessione di alcuna licenza su di essi. Chi desiderasse ricevere informazioni relative a licenze può rivolgersi per iscritto a:
IBM Director of Commercial Relations
IBM Europe
Schoenaicher Str.220
D-7030 Boeblingen
Deutschland
Per richieste di licenza relative a informazioni double-byte (DBCS) scrivere al seguente indirizzo:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
L'IBM può utilizzare o divulgare le informazioni ricevute dagli utenti secondo le modalità ritenute appropriate, senza alcun obbligo nei loro confronti.
Quanto riportato di seguito non vale nel Regno Unito o in qualsiasi altro paese in cui non sia compatibile con le leggi vigenti: QUESTO DOCUMENTO E' FORNITO "NELLO STATO IN CUI SI TROVA" SENZA ALCUNA GARANZIA ESPLICITA O IMPLICITA, IVI INCLUSE EVENTUALI GARANZIE O CONDIZIONI DI COMMERCIABILIT· ED IDONEIT· AD UNO SCOPO PARTICOLARE. Alcuni stati non consentono la rinuncia a garanzie esplicite o implicite in determinate transazioni, quindi la presente dichiarazione potrebbe non essere a voi applicabile.
Questa pubblicazione potrebbe contenere imprecisioni tecniche o errori tipografici. Le informazioni incluse in questo documento vengono modificate su base periodica; tali modifiche verranno incorporate nelle nuove edizioni della pubblicazione. L'IBM si riserva il diritto di apportare miglioramenti e/o modifiche al prodotto o al programma descritto nel manuale in qualsiasi momento e senza preavviso.
Coloro che detengono la licenza su questo programma e desiderano avere informazioni su di esso allo scopo di consentire: (i) uno scambio di informazioni tra programmi indipendenti ed altri (compreso questo) e (ii) l'uso reciproco di tali informazioni, dovrebbero rivolgersi a:
Lab Director
IBM Canada Ltd. Laboratory
8200 Warden Avenue
Markham, Ontario, Canada L6G 1C7
Queste informazioni possono essere rese disponibili secondo condizioni contrattuali appropriate, compreso, in alcuni casi, l'addebito di un canone.
Il programma su licenza descritto in questa documentazione e tutto il materiale su licenza ad esso relativo vengono forniti dall'IBM nei termini dell'IBM Customer Agreement, dell'IBM International Program License Agreement o di eventuali accordi equivalenti intercorsi tra le parti.
Le informazioni relative a prodotti non IBM sono state acquisite presso i fornitori di tali prodotti, gli annunci da loro pubblicati o altre fonti disponibili pubblicamente. L'IBM non ha verificato tali prodotti, quindi non può confermarne la qualità delle prestazioni, la compatibilità o altre dichiarazioni relative a prodotti non IBM. Eventuali quesiti sulle funzioni di prodotti non IBM dovrebbero essere indirizzati ai fornitori.
Tutti i riferimenti a siti Web non dell'IBM sono forniti unicamente a scopo di consultazione. Il contenuto di questi siti non rientra nella documentazione relativa al prodotto IBM in questione. Pertanto, l'utente si assume eventuali rischi per l'accesso a questi siti Web.
Queste informazioni possono contenere esempi relativi a dati e prospetti utilizzati in operazioni commerciali ordinarie. Perché queste vengano illustrate nel modo più dettagliato possibile, gli esempi possono includere nomi di individui, compagnie, marchi e prodotti. Tuttavia, tali nomi sono fittizi e qualsiasi riferimento ad imprese commerciali realmente esistenti è puramente casuale.
LICENZA SOGGETTA ALLE LEGGI SUL DIRITTO D'AUTORE:
Queste informazioni contengono esempi di programmi applicativi in lingua originale che illustrano le tecniche di programmazione su diverse piattaforme operative. E' possibile copiare, modificare e distribuire questi programmi, in una qualsiasi forma, per scopi di sviluppo, di utilizzo, di commercializzazione o distribuzione dei programmi applicativi conformi alle interfacce di programmi applicativi relativi alla piattaforma operativa, senza il pagamento di alcun diritto alla IBM. Questi esempi non sono stati testati approfonditamente tenendo conto di tutte le condizioni possibili. La IBM, quindi, non può garantire o assicurare l'affidabilità, la praticità o il funzionamento di questi programmi. E' possibile copiare, modificare e distribuire questi esempi di programmi sotto qualsiasi forma senza alcun pagamento alla IBM, allo scopo di sviluppare, utilizzare, commercializzare o distribuire i programmi applicativi in modo conforme alle API (Application Programming Interface) IBM.
Ogni copia o parte di questi programmi di esempio o dei lavori derivati deve necessariamente includere le informazioni sul copyright, come di seguito riportato:
(C) (nome della società) (anno). Parti di questo codice derivano dai Programmi di esempio della IBM Corp. (C) Copyright IBM Corp. 2000, 2003. Tutti i diritti riservati.
Le informazioni sull'interfaccia di programmazione consentono di creare del software applicativo tramite questo programma.
Le interfacce di programmazione di uso generale consentono di scrivere software applicativo che si avvalga dei servizi offerti dagli strumenti di questo programma.
Tuttavia, questa pubblicazione può anche contenere informazioni su diagnosi, modifiche e ottimizzazione di prestazioni. Queste informazioni vengono fornite per aiutare gli utenti a eseguire il debug del loro software applicativo.
Avvertenza: non utilizzare queste informazioni sulle diagnosi, le modifiche e la sintonizzazione come interfaccia di programmazione perché vanno soggette a cambiamenti.
I seguenti termini sono marchi della IBM (International Business Machines Corporation) negli Stati Uniti e/o in altri paesi:
Java e tutti i marchi e i logo basati su Java sono marchi della Sun Microsystems, Inc. negli Stati Uniti e/o in altri paesi.
ActiveX, Microsoft, Windows, Windows NT e il logo di Windows sono marchi della Microsoft Corporation negli Stati Uniti e/o in altri paesi.
UNIX è un marchio della The Open Group.
Nomi di altre società, prodotti o servizi, che possono essere indicati da un doppio asterisco (**), possono essere marchi di altre società.