Strumenti di distribuzione e verifica - Note sul rilascio

1.0 Introduzione
2.0 Software supportato e specifiche
3.0 Modifiche rispetto alla versione precedente
4.0 Limitazioni
   4.1 WebSphere Server deve avere codepage corrispondenti
5.0 Problemi noti
   5.1 Configurazione degli adattatori risorse J2C per WebSphere v5
   5.2 Impossibile avviare o creare WebSphere Application Server a causa di caratteri non validi
   5.3 Interrompendo l'ambiente di test di WebSphere V4.0, potrebbero essere registrati errori nel file di log
   5.4 I nomi di directory lunghi possono provocare errori nelle verifiche JSP
   5.5 Problemi con l'utilizzo di Apache Tomcat se si è disconnessi da Internet
   5.6 Esecuzione delle applicazioni Java che si connettono a WebSphere Application Server
   5.7 Esecuzione di WebSphere V4.0 Administrative Client con protezione attivata
   5.8 Versioni di WebSphere Test Environment
   5.9 Utilizzo dei costruttori nel client di verifica universale
   5.10 Impostazione dell'ID di backend utilizzando la creazione automatica di origine dati e tabelle
   5.11 Percorso classi del fornitore di DB2 JDBC su Linux
   5.12 Client di applicazioni WebSphere versione 4.0 su Linux
   5.13 Il client J2EE non riesce ad accedere al server dell'ambiente di test su un computer remoto
   5.14 Funzione di traccia con WebSphere versione 4.0
   5.15 Impossibile verificare il funzionamento delle relazioni locali EJB 2.0 nel client di verifica universale
   5.16 File non eliminati dalla disinstallazione del runtime di WebSphere V4
   5.17 Esecuzione con WebSphere MQ
   5.18 Messaggio visualizzato all'applicazione di WebSphere V4 PTF
   5.19 Creazione di origini dati e server nella console di gestione di WebSphere v5
   5.20 Spostamento delle configurazioni server e ridenominazione dei progetti server
   5.21 Opzioni di percorso per il server WebSphere
   5.22 Impostazione di un server remoto per l'utilizzo della funzione di messaggistica integrata
   5.23 Ignorare il messaggio È stato installato solo il client di messaggistica integrata nella vista Console
   5.24 Configurazione di Cloudscape 5.1
   5.25 Utilizzo del programma di creazione di tabelle e origini dati con il driver JDBC tipo 4 DB2 8.1
   5.26 Ripubblicando il server WebSphere su una macchina AIX vengono prodotti messaggi di avviso
   5.27 Utilizzo della funzione di messaggistica integrata con un server remoto AIX o Linux
   5.28 Supporto per debug veloce e sostituzione metodi attivi
   5.29 Migrazione WebSphere MQ
   5.30 Migrazione dei progetti connettori distribuiti da WebSphere Studio v5.0
   5.31 Possibile danneggiamento del server durante il salvataggio di una nuova voce di autenticazione JAAS

1.0 Introduzione

La funzione Strumenti server consente di testare e pubblicare le applicazioni J2EE in ambienti di runtime locale e remoto diversi. In questo file Readme vengono descritte le limitazioni, i problemi noti e le soluzioni associate alle seguenti funzioni di Strumenti server:

Nella Guida in linea per il test e la pubblicazione sono contenute ulteriori informazioni sulle restrizioni di Strumenti server circa i problemi riscontrati.

Per informazioni sugli ambienti runtime supportati consultare il readme del prodotto.

2.0 Software supportato e specifiche

Per utilizzare il client di verifica universale è necessario Netscape Versione 4.6 o Mozilla Versione 0.7 o successiva.

3.0 Modifiche rispetto alla versione precedente

Gli strumenti server supportano la verifica e la pubblicazione dei progetti su server WebSphere in Windows, Linux e AIX.

4.0 Limitazioni

4.1 WebSphere Server deve avere codepage corrispondenti

Quando si eseguono verifiche funzionali con i server WebSphere remoti, il computer remoto dovrà avere la stessa codepage del computer locale. L'esecuzione del server locale e remoto con codepage diverse non è supportata e potrebbe danneggiare la console.

5.0 Problemi noti

5.1 Configurazione degli adattatori risorse J2C per WebSphere v5

È possibile che venga visualizzato un errore quando si sceglie Aggiungi nella pagina J2C dell'editor di configurazione di WebSphere v5. Per evitare questo problema, configurare il modulo connettore all'interno di un EAR, oppure procedere come segue:

1. Attivare la console di gestione di WebSphere ed avviare il server.

2. Aprire e collegarsi alla console di gestione. Selezionare Risorse > Adattatori risorse a sinistra.

3. Scegliere Nuovo. Immettere il Nome del modulo connettore e specificare il percorso completo della cartella connectorModule interna al progetto. Ad esempio, C:\workspace\myConnector\connectorModule.

4. Scegliere Applica quindi Aggiorna per aggiornare il progetto server nell'IDE. Se si desidera apportare ulteriori modifiche, adesso è possibile continuare ad utilizzare l'editor della ù configurazione server.

5.2 Impossibile avviare o creare WebSphere Application Server a causa di caratteri non validi

Se si installa WebSphere Studio in una directory il cui nome contiene il simbolo del dollaro ($) o altri caratteri non considerati validi, quali #, %, + o *, il server WebSphere potrebbe non essere creato o non verrà avviato correttamente. Per evitare questo problema, non installare WebSphere Studio in una directory contenente tali caratteri.

Durante la creazione di un server WebSphere o di un progetto server che contiene un server WebSphere, non includere i caratteri #, %, & o * nel nome. WebSphere Application Server non supporta tali caratteri.

5.3 Interrompendo l'ambiente di test di WebSphere V4.0, potrebbero essere registrati errori nel file di log

Se l'ambiente di test WebSphere V4.0 viene interrotto su Linux, potrebbero essere visualizzati i seguenti errori nella vista Console:

Impossibile richiamare il file di log condiviso /opt/wsappdev/plugins/com.ibm.etools.websphere.runtime/logs/activity.log.lck
Traccia dello stack:
com.ibm.ejs.ras.SharedLogLockException
 at com.ibm.ejs.ras.SharedLogBase.acquireHostLock(SharedLogBase.java:251)
 at com.ibm.ejs.ras.SharedLogWriter.log(SharedLogWriter.java:255)
...
Eccezione precedente:
Messaggio:
 null
Traccia dello stack:
java.io.IOException: autorizzazione negata
 at java.io.UnixFileSystem.createFileExclusively(Native Method)
 at java.io.File.createNewFile(File.java:697)
...

Questo problema è dovuto al fatto che il server non riesce a inserire dati nel file activity.log. I processi del server potranno essere interrotti correttamente anche se si ricevono questi messaggio di errore che possono essere ignorati.

5.4 I nomi di directory lunghi possono provocare errori nei test JSP

Se si utilizza uno spazio di lavoro in una directory con percorso lungo o si scelgono nomi lunghi per un progetto Enterprise Application o un progetto Web, è possibile che venga visualizzato il seguente messaggio di errore quando si prova ad eseguire una pagina JSP:

Messaggio di errore: JSPG0113E: file JSP
"Xxx/Yyy_jsp_0.java (Nome file troppo lungo)" non trovato

Se si riceve questo errore, è possibile effettuare una delle seguenti azioni:

5.5 Problemi con l'utilizzo di Apache Tomcat se si è disconnessi da Internet

Nel file predefinito web.xml fornito con Apache Tomcat è riportato un riferimento a un file DTD su Internet. Per questo motivo, i server Tomcat non vengono avviati quando si è disconnessi da Internet. In WebSphere Studio, questi riferimenti sono stati rimossi dalla configurazione del server Tomcat versione 3.2, pertanto è possibile utilizzarlo anche in modalità autonoma. Se si importa una configurazione del server Tomcat dall'esterno di WebSphere Studio o si utilizza il server Tomcat versione 4.0, è possibile che si verifichino problemi quando si opera scollegati da Internet. Se ciò accade, procedere come segue per rimuovere il riferimento.

  1. Creare una copia di backup del file web.xml dalla configurazione del server Tomcat.
  2. Modificare il file web.xml nella configurazione del server Tomcat mediante un editor di testo.
  3. Rimuovere l'intero elemento DOCTYPE dal file.
  4. Salvare e chiudere l'editor.
Se si riscontrano problemi all'avvio del server, può essere necessario collegarsi a Internet e aggiungere di nuovo l'elemento DOCTYPE utilizzando il file web.xml di backup.

5.6 Esecuzione di applicazioni Java che si connettono a WebSphere Application Server

WebSphere Application Server presenta una restrizione indicante che tutte le applicazioni Java che utilizzano il client WebSphere per collegarsi ai bean enterprise in esecuzione su un server WebSphere devono utilizzare lo stesso livello dell'ORB Java IBM utilizzato per eseguire la generazione del client WebSphere. Se non si utilizza lo stesso livello ORB, è possibile che venga visualizzato un messaggio di errore, come quello riportato di seguito, durante l'esecuzione dell'applicazione client:

java.lang.NoClassDefFoundError: com/ibm/rmi/iiop/GIOPVersionException

Per verificare che venga utilizzato il livello ORB corretto, è possibile eseguire l'applicazione client utilizzando il JRE WebSphere. Per eseguire questa operazione, completare i seguenti passi:

  1. Aprire la finestra di dialogo Avvia configurazioni utilizzando le voci di menu della prospettiva Debug Esegui > Esegui o Esegui > Debug
  2. Selezionare la configurazione di avvio dell'applicazione Java che si desidera modificare.
  3. Passare alla pagina JRE e selezionare il JRE WebSphere appropriato dalla casella combinata.
  4. Applicare le modifiche.

Altrimenti, è possibile eseguire l'applicazione client con JRE per controllare che venga utilizzato il livello ORB corrispondente. Per eseguire questa operazione, completare i seguenti passi:

  1. Aprire la finestra di dialogo Avvia configurazioni utilizzando le voci di menu della prospettiva Debug Esegui > Esegui o Esegui > Debug
  2. Selezionare la configurazione di avvio dell'applicazione Java che si desidera modificare.
  3. Passare alla pagina Argomenti e aggiungere quanto segue al campo Argomenti VM:
    -Xbootclasspath/p:WAS_installdir\java\jre\lib\ext\ibmorb.jar
    ricordando che WAS_installdir indica la directory che contiene il runtime, ad esempio c:\Programmi\IBM\WebSphere Studio\runtimes\aes_v4
  4. Applicare le modifiche.

5.7 Esecuzione di WebSphere V4.0 Administrative Client con protezione attivata

Il client di gestione WebSphere versione 4 non può essere avviato direttamente dal workbench quando la protezione è abilitata. Per avviare il client di gestione procedere come segue:

  1. Avviare il server WebSphere.
  2. Aprire un browser Web e immettere il seguente URL: http://[localhost:8080]/admin, dove [localhost:8080] è il nome server e la porta utilizzati.
  3. Immettere l'id utente e la password utilizzati per configurare la protezione. Fare clic su Invia.
  4. Nel riquadro a destra, scegliere Configurazione > Apri.
  5. Selezionare "Immetti nome file completo sul server".
  6. Immettere il percorso completo della configurazione server nel campo di testo. Ad esempio: C:\studio\eclipse\workspace\Servers\was.wsc\server-cfg.xml.
  7. Scegliere OK.

5.8 Versioni di WebSphere Test Environment

L'ambiente di test di WebSphere versione 4 si basa su WebSphere versione 4.06. L'ambiente di test di WebSphere versione 5 si basa su WebSphere versione 5.02. Quando si esegue la migrazione da una versione precedente di WebSphere Studio, gli e-fix dell'ambiente di test WebSphere verranno rimossi e sarà necessario reinstallarli manualmente.

5.9 Utilizzo dei costruttori nel client di verifica universale

Quando si utilizza il client di verifica universale è possibile creare oggetti che utilizzano le interfacce come parametri nella pagina dei parametri. Gli oggetti che vengono creati dai parametri con tipi di interfaccia è necessario che utilizzino la sezione dei riferimenti di classe.

Caricare prima e creare un oggetto del tipo astratto o di interfaccia. Caricare quindi la classe che contiene il costruttore con il tipo di interfaccia o astratto. Scegliere l'oggetto creato nella pagina dei parametri.

5.10 Impostazione dell'ID di backend utilizzando la creazione automatica di origine dati e tabelle

Quando si utilizza la creazione automatica di origine dati e tabelle, per eseguire la verifica funzionale dell'unità dei bean enterprise CMP, è necessario impostare Cloudscape come ID di backend. Per impostazione predefinita, l'ID di backend corrente è vuoto, ma durante il runtime viene utilizzato DB2, a meno che non sia stato specificato un ID diverso.

Per specificare Cloudscape come ID di backend, effettuare le operazioni descritte di seguito:

  1. Nella vista Gerarchia J2EE, fare clic con il pulsante destro del mouse su progetto EJB e selezionare Apri con > Editor del descrittore di distribuzione.
  2. Scorrere verso il basso fino alla sezione dell'ID di backend.
  3. Fare clic su Aggiorna accanto al campo Corrente, per caricare tutti gli ID di backend disponibili.
  4. Nel campo Corrente, selezionare la mappa di Cloudscape generata dal menu a discesa. Ad esempio, CLOUDSCAPE_V50_1.
  5. Salvare le modifiche e chiudere l'editor.

5.11 Percorso classi del fornitore di DB2 JDBC su Linux

Il percorso classi del fornitore DB2 JDBC su Linux è impostato su ${DB2_JDBC_DRIVER_PATH}/db2java.zip. Il percorso di installazione di DB2 non può essere rilevato su Linux, quindi sarà necessario rimuovere manualmente questa voce del percorso classi ed aggiungere una nuova voce con il percorso corretto nell'editor del server se si desidera utilizzare un'origine dati DB2 su Linux.

5.12 Client di applicazioni WebSphere versione 4.0 su Linux

Per accedere ai bean enterprise da un client di applicazioni in esecuzione su WebSphere versione 4.0, è necessario specificare la porta bootstrap ORB corretta del server. Questa impostazione può essere eseguita impostando l'URL del fornitore JNDI per il contesto iniziale oppure, se si utilizzano i bean di accesso, specificando la porta bootstrap ORB nella riga comandi aggiungendo -CCBootstrapPort=2809 come argomento del programma nella pagina Argomenti della procedura guidata Configurazioni di avvio.

5.13 Client J2EE non in grado di accedere al server dell'ambiente di test su un computer remoto

Può essere visualizzato org.omg.CORBA.COMM_FAILURE quando si tenta di accedere a un server dell'ambiente di test da un client J2EE in esecuzione su un computer remoto. Per risolvere il problema, è necessario configurare il nome host del bootstrap ORB definito nella configurazione server remoto. Per modificare il nome host del bootstrap ORB, andare alla pagina Porte dell'editor di server e impostare il campo Nome host nella sezione della porta del bootstrap ORB sul nome host remoto.

A questo punto, salvare le modifiche apportate e riavviare il server dell'ambiente di test affinché le modifiche abbiano effetto.

5.14 Funzione di traccia con WebSphere versione 4.0

Se si disattiva la funzione di traccia per WebSphere versione 4.0, si verificherà una ConnectionException nella console e sarà impossibile arrestare il server in modo corretto.

5.15 Impossibile verificare il funzionamento delle relazioni locali EJB 2.0 nel client di verifica universale

Il client di verifica universale non supporta le transazioni attraverso richieste multiple. Ciò rende impossibile la verifica delle relazioni locali EJB 2.0, dal momento che non è possibile ottenere con una richiesta singola l'insieme contenente le relazioni ed utilizzarne i contenuti.

5.16 File non eliminati dalla disinstallazione del runtime di WebSphere V4

Una volta completata la disinstallazione del runtime di WebSphere V4, la directory WS_installdir/runtimes/aes_v4 potrebbe ancora essere presente al termine del processo. In questo caso è necessario intervenire manualmente per eliminare la directory, altrimenti si verificheranno dei problemi con il supporto per il server WebSphere V4. Tali interventi sono necessari anche nel caso in cui WebSphere Studio venga disinstallato e poi reinstallato nella stessa posizione.

5.17 Esecuzione con WebSphere MQ

Se è stato installato il componente WebSphere MQ, sarà necessario creare uno script per avviare WebSphere Studio con le variabili di ambiente e i percorsi corretti. Effettuare i seguenti passaggi:

  1. Con VI o o un altro editor di testo, creare il file wsappdevmq.sh.
  2. Modificare il file ed aggiungere il seguente testo:
     	export PATH=$PATH:/opt/mqm/bin:/opt/mqm/java/bin:/opt/wemps/bin 	export LD_LIBRARY_PATH=/opt/mqm/lib:/opt/mqm/java/lib:/opt/wemps/lib:$LD_LIBRARY_PATH 	export WEMPS_REGISTRY=/var/wemps/registry 	wsappdev50
  3. Salvare il file e chiudere l'editor.
  4. Immettere il comando chmod a+x wsappdevmq.sh
  5. Utilizzare lo script wsappdevmq.sh invece di wsappdev per avviare WebSphere Studio.

5.18 Messaggio visualizzato all'applicazione di WebSphere V4 PTF

Durante l'applicazione della PTF per WebSphere V4, è possibile che venga visualizzato il messaggio "NOTA: Rigenerare la configurazione di plugin dopo aver riavviato il server in modo da aggiornare il file plugin-cfg.xml". Il messaggio può essere ignorato.

5.19 Creazione di origini dati e server nella console di gestione di WebSphere v5

Durante l'aggiunta di origini dati o durante la creazione di server mediante la console di gestione di WebSphere v5 in WebSphere Studio, potrebbe essere visualizzata l'eccezione NullPointerException o altri errori. Utilizzare una delle seguenti soluzioni alternative:

  1. Se si desidera creare un'origine dati, utilizzare il server WebSphere v5. È possibile aprire l'editor facendo doppio clic sul server WebSphere v5 nella vista Server o nella vista Configurazioni server. Passare alla pagina Origine dati per aggiungere, modificare o rimuovere le origini dati dal server.
  2. Arrestare il server.
    1. Copiare la directory dei modelli dalla seguente directory (dove WS_installdir è la directory in cui è stato installato WebSphere Studio):
      WS_installdir\runtimes\base_v5\config\templates
      nello spazio di lavoro corrente in:
      workspace_ dir\server_ project\server_ name.wsc
    2. Riavviare il server e provare nuovamente.

5.20 Spostamento delle configurazioni server e ridenominazione dei progetti server

L'associazione tra un server e la relativa configurazione, include il progetto in cui si trova la configurazione server. Ridenominando un progetto server o spostando una configurazione server in un progetto diverso, le associazioni di tutti i server che utilizzano le configurazioni risulteranno interrotte. Per risolvere il problema, nella vista Server, selezionare il server con il tasto destro del mouse e scegliere Cambia configurazione > nome_configurazione_server per associare nuovamente la configurazione al server.

5.21 Opzioni di percorso per il server WebSphere

La funzionalità per le opzioni di percorso nella pagina di ambiente dell'editor del server WebSphere non funziona. Il percorso immesso nel campo Percorso libreria Java verrà aggiunto al percorso esistente del server. Non sarà necessario controllare dove verranno aggiunti i dati, ad esempio se all'inizio, alla fine o in sostituzione del percorso server corrente.

5.22 Impostazione di un server remoto per l'utilizzo della funzione di messaggistica integrata

Nell'argomento Impostazione di un server per l'utilizzo della funzione di messaggistica integrata alcune parti del contenuto della sezione Ambiente di test contengono istruzioni relative alla sezione Server remoto. Nella configurazione server locale o remota, è necessario definire quanto segue: WAS_PUBSUB_ROOT, MQ_INSTALL_ROOT e un gestore code sul server. Inoltre è necessario aggiungere una voce nella sezione ws.ext.dirs della configurazione server che faccia riferimento alla directory java/lib in cui è installato WebSphere MQ.

Le istruzioni di installazione e impostazione del gestore code sono riportate nella sezione Ambiente di test di questo argomento. Il file batch createmq esiste anche sul computer autonomo di WebSphere Application Server  nella stessa directory relativa alla struttura di installazione di WebSphere Application Server. Se si desidera distribuire il server da WebSphere Studio un WebSphere Application Server remoto, sarà necessario eseguire questa operazione.

Nota: se la funzione di messaggistica integrata è stata installata con il programma di installazione di WebSphere Studio, non sarà necessario eseguire createmq.bat né impostare il file variables.xml o creare un file batch per avviare il workbench per assicurarsi che i binari MQ siano stati inseriti nel percorso server di WAS. Sarà necessario però eseguire l'aggiunta a ws.ext.dirs sul server. Questa attività è necessaria solo se la funzione di messaggistica integrata è stata installata con il programma di installazione di WebSphere Application Server.

5.23 Ignorare il messaggio È stato installato solo il client di messaggistica integrata nella vista Console

Durante l'avvio dell'ambiente di test WebSphere v5.0, è possibile che venga visualizzato il messaggio nella vista Console "È stato installato solo il client di messaggistica integrata", anche se la funzione, un componente facoltativo, non è stata installata come parte dell'installazione di WebSphere Studio. Questo messaggio può essere ignorato e non indica che la funzione di messaggistica è stata installata, ma che alcune variabili di configurazione del server sono state definite per il server di verifica, il che genera il messaggio.

5.24 Configurazione di Cloudscape 5.1

Per installare Cloudscape 5.1, eseguire il file installCloudscape51.bat su Windows o Cloudscape51.sh su Linux. Il file si trova nella directory WS_installdir/runtimes/base_v5/cloudscape51 (dove WSinstalldir è la directory in cui è stato installato WebSphere Studio. Il programma di installazione avvierà il programma di installazione Cloudscape specifico per WebSphere. Quando viene richiesto il Nome directory, indicare la directory WS_installdir/runtimes/base_v5.

Nota: dopo aver installato Cloudscape 5.1, non sarà possibile eseguire o disporre di origini dati definite di Cloudscape 5.0. Se si desidera eseguire Cloudscape 5.0, è necessario disinstallare Cloudscape 5.1 e rimuovere le origini dati Cloudscape 5.1 o modificarle in origini dati Cloudscape 5.0.

5.25 Utilizzo del programma di creazione di tabelle e origini dati con il driver JDBC tipo 4 DB2 8.1

Il programma di creazione tabelle e origini dati supporta la creazione automatica delle tabelle del database e delle origini dati associate configurate nel server di applicazioni in modo da semplificare la verifica funzionale dei bean CMP nell'ambiente di test di WebSphere. La versione di DB2 supportata è DB2 V8.1, con il driver JDBM di tipo 4, che funziona sui sistemi in cui DB2 v8.1 è installato localmente o in remoto.

Per generare le tabelle e le origini dati per DB2, sul computer di sviluppo dovranno essere presenti due file JAR. Il primo è lo stesso driver JDBC, contenuto nel file db2jcc.jar, mentre l'altro è un file JAR di licenza chiamato db2jcc_license_cisuz.jar. Generalmente tali file si trovano in DB2_installdir/SQLLIB/java  (dove DB2_installdir è la directory in cui è stato installato DB2). Per i sistemi in cui DB2 è installato sul computer di sviluppo, vengono rilevati i percorsi, dopodiché non sono richieste altre attività. Se i percorsi non vengono rilevati automaticamente, specificarli manualmente nella finestra.

Se DB2 è installato su una macchina remota, è necessario indicare il percorso completo dei due file JAR nella finestra di connessione DB2 visualizzata durante la creazione delle tabelle. La configurazione è automatica, quindi non è necessario specificare alcuna impostazione. Se non viene fornito il percorso dei due file JAR, potrebbe verificarsi la seguente eccezione sia durante la creazione delle tabelle che al runtime:

com.ibm.db2.jcc.c.SqlException: la versione del driver IBM Universal JDBC
utilizzato non dispone di licenza per la connessione a DB2 per database Unix/Windows.  
Per connettersi a questo server DB2, è necessaria una copia su licenza di IBM DB2 Universal Driver per JDBC e SQLJ.

Copia su licenza significa che il file db2jcc_license_cisuz.jar viene aggiunto al percorso dopo db2jcc.jar. Anche se solo il driver tipo 4 è supportato per il programma di creazione di tabelle e origini dati, è possibile esportare manualmente gli schemi DB2 mediante gli strumenti RSC.

Nella finestra delle impostazioni di connessione di DB2, viene richiesto di indicare il "percorso per db2jcc.jar". Questo implica il percorso a questo jar e al jar di licenza. Il pulsante Sfoglia consente di selezionare più file, quindi selezionare sia il file db2jcc.jar che il file db2jcc_license_cisuz.jar. Se viene selezionato un solo file, il campo di input rimarrà vuoto. Per chiudere la finestra e continuare, sarà necessario selezionare entrambi i file o indicare il percorso manualmente.

5.26 Ripubblicando il server WebSphere su una macchina AIX vengono prodotti messaggi di avviso

Se viene ripubblicato un server WebSphere su un computer AIX, è possibile che vengano visualizzati alcuni messaggi di avviso che informano che non è stato possibile eliminare alcuni file nella finestra di pubblicazione. Tali messaggi possono essere ignorati.

5.27 Utilizzo della funzione di messaggistica integrata con un server remoto AIX o Linux

Se la funzione di messaggistica integrata è stata installata su un server remoto AIX o Linux, procedere come segue:

  1. In WebSphere Studio, nella pagina Ambiente dell'editor del server, nella sezione ws.ext.dirs, scegliere Aggiungi cartella esterna ed aggiungere la directory contenente le classi di implementazione Java della funzione di messaggistica integrata.
  2. Nella sezione del percorso della libreria Java, immettere il percorso dei file binari MQ. Salvare le modifiche.
  3. Sul computer remoto, aggiungere la variabile di ambiente WEMPS_REGISTRY al file serverconfig.xml situato nella directory in cui è stato installato Agent Controller. Nel file serverconfig.xml, questa variabile si trova nella sezione di configurazione dell'applicazione per wteRemoteV5.exe. Ad esempio:
    <Variable name="WEMPS_REGISTRY"
    position="prepend" value="/var/wemps/registry"></Variable>
    dove /var/wemps/registry è il percorso di questa variabile.

5.28 Supporto per debug veloce e sostituzione metodi attivi

Le funzioni di debug veloce e di sostituzione metodi attivi sono supportate solo quando il debug viene eseguito nell'ambiente di test di WebSphere V5. Il debug delle applicazioni esterne a questo ambiente di test non è supportato.

5.29 Migrazione WebSphere MQ

Il componente WebSphere MQ non supporta la compatibilità tra versioni diverse. Assicurarsi che la versione di WebSphere MQ utilizzata abbia lo stesso livello di fixpack dell'ambiente di test WebSphere o del server WebSphere in cui si esegue la distribuzione.

Ad esempio, non utilizzare WebSphere MQ installato da WebSphere Studio v5.0 con l'ambiente di test di WebSphere v5.0.2. In questo caso, disinstallare WebSphere MQ ed installare la versione fornita con WebSphere Studio v5.1.

5.30 Migrazione dei progetti connettori distribuiti da WebSphere Studio v5.0

Gli spazi di lavoro creati in WebSphere Studio v5.0 contenenti progetti connettore distribuiti a un ambiente di test WebSphere o a un server WebSphere, non vengono migrati automaticamente durante il passaggio a una versione successiva. È possibile che vengano ricevuti errori durante la pubblicazione dei progetti connettore sul server.

Per risolvere il problema, nella vista Server, selezionare il server con il tasto destro del mouse e scegliere Aggiungi e rimuovi progetti. Rimuovere il progetto EAR dal server e aggiungerlo nuovamente. In tal modo la configurazione del server WebSphere viene corretta in modo che i progetti connettore possano essere correttamente distribuiti.

5.31 Possibile danneggiamento del server durante il salvataggio di una nuova voce di autenticazione JAAS

Se in un editor di server V5 viene creata e salvata una nuova voce di autenticazione JAAS senza uscire dall'editor e successivamente nella scheda Origine dati si aggiunge un'origine dati V5, verrà visualizzata la finestra File modificato. Per non danneggiare la configurazione del server, scegliere NO.

Visualizza il file Readme principale