© Copyright International Business Machines Corporation 2006. Tutti i diritti riservati. 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 IBM Corp.
L'opzione Riduci i file dell'applicazione copiati sul server è supportata da WebSphere® Application Server 6.0.2.5 e versioni successive. Nell'editor del server di WebSphere Application Server V6.0 è presente una casella di controllo per tale opzione; l'opzione viene ignorata se è selezionata per server antecedenti alla versione 6.0.2.5.
Se un modulo Enterprise JavaBean (EJB) viene condiviso tra più progetti EAR in esecuzione su WebSphere Application Server e uno dei progetti EAR viene rimosso dal server, altri progetti EAR devono essere riavviati prima che possano accedere alle risorse, ad esempio bean EJB, nel progetto EJB.
Se tale operazione non viene eseguita, potrebbero essere visualizzati messaggi di errore simili a quelli di seguito riportati. Tali errori si verificano perché il nome JNDI (Java Naming and Directory Interface) nel progetto EJB viene rimosso dal server quando viene eliminato l'EAR.
Di seguito viene riportato un esempio di messaggio di errore:
00000028 SystemOut O javax.naming.NameNotFoundException: Context: myCell/nodes/myNode/servers/server1, name: ejb/ejbs/Session20Home: First component in name Session20Home not found. [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
at com.ibm.ws.naming.jndicos.CNContextImpl.processNotFoundException(CNContextImpl.java:4730)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1907)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1862)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1552)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.java:1354)
at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:172)
at javax.naming.InitialContext.lookup(InitialContext.java:363)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.lookupAndCacheHome(AbstractAccessBean.java:224)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.getGlobalHome(AbstractAccessBean.java:216)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.getHome(AbstractAccessBean.java:249)
at ejbs.Session20AccessBean.ejbHome(Session20AccessBean.java:50)
at ejbs.Session20AccessBean.instantiateEJB(Session20AccessBean.java:80)
at ejbs.Session20AccessBean.foo(Session20AccessBean.java:91)
A causa di diversi comportamenti e interazioni tra gli ambienti di runtime Eclipse e WebSphere, è necessario effettuare ulteriori operazioni durante l'esecuzione di client di applicazioni Websphere multi-thread tramite la finestra di dialogo di avvio configurazioni client applicazioni. La finestra di dialogo per l'avvio configurazioni client applicazioni è disponibile nella prospettiva J2EE quando si selezionaEsegui> Esegui sulla barra degli strumenti del prodotto. Se il client utilizza più thread oppure adopera framework che usano thread aggiuntivi, ad esempio Swing, è necessario completare le seguenti ulteriori operazioni:
- Nella finestra di dialogo di avvio configurazioni client applicazioni, selezionare la schedaArgomenti. Nella casella di testo Argomenti VM specificare il seguente parametro:
-Dosgi.noShutdown=true- Accertarsi che l'applicazione client richiami System.exit()
Se tali argomenti non vengono specificati, potrebbero verificarsi problemi relativi al caricamento classi o a JVM (Java™ Virtual Machines) che non termina al completamento dell'esecuzione dell'applicazione.
Supponendo di avere un progetto, ad esempio un progetto Client di applicazioni, con le seguenti configurazioni:
- il facet del progetto per Java è impostato sulla versione 1.4
- l'opzione per la sostituzione del metodo hot del runtime del server di destinazione per questo progetto è abilitata nella relativa configurazione del server
Il pulsante Riprendi nella vista Debug potrebbe non funzionare correttamente. Ad esempio, quando l'applicazione viene eseguita sul server in modalità debug, si tenta di cambiare l'origine al runtime e quindi si utilizza il pulsante Riprendi per continuare ad eseguire il debug dell'applicazione. La modifica della sostituzione del metodo hot al codice di origine potrebbe non essere applicata.
Tentare facendo clic due volte sul pulsante Riprendi perché le modifiche del runtime abbiano effetto.
Nota: questo problema non si verifica quando viene impostato il facet del progetto per Java sulla versione 5.0.
Il pulsante Rimuovi della finestra di dialogo Gestisci server WebSphere condivisi non funziona correttamente.
Suggerimento: per aprire la finestra di dialogo Gestisci server WebSphere condivisi:
- Nella barra degli strumenti, selezionare Finestra > Preferenze. Si apre la finestra di dialogo Preferenze.
- Nel riquadro sinistro, selezionare Server > WebSphere > WebSphere v51.
- Nel riquadro destro, accanto al campo Server WebSphere condivisi, fare clic sul pulsante Gestisci. Viene aperta la finestra dialogo Gestisci server WebSphere condivisi.
Se si utilizza il pulsante Rimuovi, il server appare come rimosso. Tuttavia, se si chiude e si apre nuovamente la finestra di dialogo e si aggiornano le informazioni sul server remoto, il server precedentemente rimosso non scompare dalla finestra di dialogo.
Per risolvere il problema, è possibile rimuovere manualmente la voce relativa al server condiviso procedendo nel modo seguente:
- Aprire il file id.txt che si trova nella seguente directory:
<directory>/plugins/com.ibm.etools.websphere.tools*/properties
dove <directory> è la directory di installazione di Agent Controller.- Eliminare la voce che si riferisce al server condiviso da rimuovere.
- Rimuovere la directory di distribuzione WebSphere specificata per il particolare server condiviso durante la creazione del server e tutte le relative directory secondarie. Esempi di directory secondarie da rimuovere nella directory di distribuzione di WebSphere sono: config, installedApps, temp e altre directory e file residenti in tale directory.
- Nella finestra di dialogo Gestisci server WebSphere condivisi, specificare un nome host e fare clic sul pulsante Aggiorna per verificare che il server condiviso sia stato effettivamente rimosso.
In caso di server aggiuntivi, ad esempio server HTTP IBM, installati nello stesso profilo di WebSphere Application Server v6.x, la pagina delle impostazioni del server WebSphere della procedura guidata Nuovo server potrebbe non essere in grado di individuare i numeri di porta SOAP o RMI (Remote Method Invocation) corretti. Inoltre, il numero di porta per la console di gestione potrebbe non essere richiamato.
Quando la procedura guidata Nuovo server non è in grado di individuare i numeri di porte effettivi definiti per un server, il comportamento predefinito consiste nel precompilare i campi delle porte con i numeri di porta predefiniti: 2809 per RMI e 8880 per SOAP.
Nel caso vengano definiti numeri di porta non corretti, potrebbero verificarsi i seguenti problemi:
- Impossibile collegarsi al nuovo server, ad esempio per avviarlo o arrestarlo.
- Impossibile aprire la console di gestione per questo nuovo server. Di conseguenza, potrebbe essere restituito un errore di porta di console di gestione non definita.
- Impossibile eseguire le applicazioni su questo server, ad esempio il comando Esegui su server non funziona
Soluzione temporanea:
- Determinare i valori delle porte di un profilo configurato facendo riferimento ai relativi file di configurazione del server. I valori delle porte vengono memorizzati nel file serverindex.xml, che si trova nella seguente directory:
<directory>\profiles\<nomeProfilo>\config\cells\<nomeCella>\nodes\<nomeNodo>, dove <directory> è la directory di installazione di WebSphere Application Server.
Utilizzare il file serverindex.xml per compilare la seguente tabella e determinare i numeri di porta effettivi definiti per il server:
Nome porta Descrizione porta Numero di porta predefinito Numero di porta assegnato SOAP_CONNECTOR_ADDRESS SOAP 8880 BOOTSTRAP_ADDRESS RMI 2809 WC_adminhost Console di gestione 9060 WC_defaulthost Trasporto HTTP 9080 - Per collegarsi al server specificare il numero di porta RMI o SOAP corretto in fase di creazione del server.
- Per avviare la console di gestione, utilizzare un browser Web esterno e immettere nel campo dell'indirizzo l'URL della porta corretta della console di gestione:
http://<nome_macchina>:<hostammin_WC>/IBM/console
Ad esempio: http://localhost:9060/IBM/console- Per eseguire le applicazioni sul server immettere il comando Esegui su server. Quando viene aperto il browser Web, correggere l'URL con il numero di porta del trasporto HTTP definito per il server.
http://<nome_macchina>:<hostpredefinito_WC>/<RootContesto>/<pagina_avvio_applicazione>
Ad esempio: http://localhost:9080/MyApplication/index.jsp
Nota: il server definito automaticamente nella vista Server potrebbe non fare riferimento ai numeri di porta corretti del server effettivo. In questo caso, utilizzare la soluzione temporanea precedentemente indicata.
Lo strumento di gestione profili è uno strumento di WebSphere Application Server che consente di creare il profilo per ciascun ambiente di runtime. Per avviare lo strumento di gestione profili di WebSphere Application Server è possibile utilizzare il workbench. Tale strumento, tuttavia, non funziona con un processore a 64 bit. Utilizzare, quindi, la strumento della riga comandi manageprofiles fornito da WebSphere Application Server.
Su sistemi operativi Windows, se viene utilizzata la porta RMI (Remote Method Invocation) per collegarsi a WebSphere Application Server v6.x, potrebbero verificarsi lunghi ritardi nello stabilire una connessione dopo aver perso la connettività di rete. Ciò può verificarsi anche se il server è locale e la connettività di rete viene persa solo temporaneamente, come avviene comunemente in un ambiente di rete wireless.
Se il server è stato avviato, ma lo stato nelle viste Server indica che è arrestato o in fase di avvio, verificare se è possibile stabilire una connessione al server cambiando connessione da RMI a SOAP. Lo stato del server dovrebbe diventare Avviato.Sono disponibili due opzioni per stabilire una connessione a un server in un ambiente di rete wireless:
- L'opzione più semplice e più sicura è cambiare connessione per utilizzare la porta SOAP. Dopo la perdita della connettività di rete, la ripresa di una connessione SOAP è più rapida rispetto a una connessione RMI.
- Se è necessario utilizzare una connessione RMI, è possibile tentare di modificare le impostazioni predefinite relative alla memorizzazione nella cache del DNS (Domain Name System) sul sistema operativo Windows. Per ulteriori informazioni, fare riferimento al seguente articolo del supporto Microsoft:
http://support.microsoft.com/kb/318803
Il sistema operativo Windows presenta una funzione integrata di memorizzazione nella cache del DNS che gestisce i nomi host risolti. Ciò consente un'inversione più veloce nell'emissione di ricerche DNS. Tuttavia, ciò presenta anche uno svantaggio, in quanto se la ricerca di un DNS non sortisce esito positivo, il sistema operativo Windows memorizza nella cache il valore errato, per un tempo predefinito di 300 secondi. Di conseguenza, anche se il server DNS è in grado di risolvere la ricerca subito dopo, la ricerca non viene effettivamente tentata fino alla scadenza del tempo della cache.Ciò implica che dopo una ricerca di DNS non riuscita con impostazioni predefinite possono trascorrere anche 5 minuti prima che venga effettivamente eseguito un nuovo tentativo. Impostando il tempo della cache su 0 secondi si forza il sistema operativo Windows a non memorizzare mai nella cache le query di ricerca DNS con esito negativo, consentendo la riconnessione non appena il DNS diventa disponibile.
Di seguito viene riportato un esempio di disabilitazione della memorizzazione nella cache delle ricerche DNS con esito negativo su sistemi operativi Windows:
Nella seguente chiave di registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Aggiungere uno dei seguenti valori di registro:
- Per Windows XP/2003:
"MaxNegativeCacheTtl"=dword:00000000- Per Windows 2000:
"NegativeCacheTime"=dword:00000000
Pubblicare nuovamente l'applicazione, riavviarla o disinstallarla e reinstallarla non è sufficiente per applicare alcune modifiche di risorse definite nella pagina Distribuzione dell'editor del descrittore di distribuzione sul server. Una modifica del nome database di un'origine dati nella pagina Distribuzione dell'editor è una tra le diverse modifiche che il server non è in grado di applicare.
Per risolvere temporaneamente il problema e applicare le modifiche sul server, procedere come segue:
- Arrestare il server.
- Nella vista Server, fare clic con il pulsante destro del mouse e selezionare Arresta.
- Nella vista Server, attendere che lo stato del server sia Arrestato e continuare con il passo successivo.
- Avviare il workbench.
NOTA: se non è possibile riavviare il server, è necessario utilizzare le funzioni del sistema operativo per arrestare il processo java su cui è in esecuzione in server. In alternativa, è possibile riavviare il workbench e quindi tentare di riavviare il server.- Avviare il server.
- Nella vista Server, fare clic con il pulsante destro sul server e selezionare Avvia.
- Nella vista Server, attendere che la nuova pubblicazione venga completata e che lo stato del server e dell'applicazione diventi Avviato, quindi continuare con il passo successivo.
- Eseguire l'applicazione sul server, utilizzando ad esempio il comando Esegui su server. Il server, a questo punto, dovrebbe essere in grado di applicare le modifiche dall'editor del descrittore di distribuzione applicazioni.
Se viene aggiunto un file JAR di utilità alle librerie Web da un progetto Web e si fa riferimento alle classi presenti nel file JAR nel codice, se si tenta di eseguire l'applicazione sul server potrebbe essere restituito l'errore java.lang.NoClassDefFoundError.
Per risolvere temporaneamente il problema, dopo l'aggiunta di un file JAR di utilità al modulo EAR, aggiungere il file JAR alle dipendenze dei moduli J2EE del progetto Web procedendo come segue:
- Aggiungere un file JAR di utilità al modulo EAR. Per informazioni dettagliate, consultare l'argomento relativo all'aggiunta dei file JAR di utilità del progetto nella guida del prodotto.
- Fare clic sul pulsante destro del mouse sul progetto Web e selezionare Proprietà. Viene aperta la finestra di dialogo Proprietà.
- Selezionare Dipendenze moduli J2EE.
- Nella scheda Moduli J2EE nella colonna JAR/Modulo, selezionare la casella di controllo accanto al file JAR di utilità.
Se WebSphere Application Server V6.1 è in esecuzione su una connessione SOAP protetta, non è possibile stabilire un'altra connessione SOAP a WebSphere Application Server V6.0. Lo stesso problema si verifica nell'ordine inverso; se, ad esempio, WebSphere Application Server V6.0 è in esecuzione su una connessione SOAP protetta, non è possibile stabilire una connessione SOAP protetta a WebSphere Application Server V6.1. Tuttavia, il problema non si verifica se il server è stato definito nella vista Server e lo stato non è specificato.
Per risolvere temporaneamente il problema, utilizzare una connessione RMI (Remote Method Invocation) al server anziché una connessione SOAP, oppure utilizzare una connessione SOAP non protetta.
Se il server remoto è arrestato, facendo clic sul pulsante Fine la procedura guidata Nuovo server potrebbe impiegare più tempo per terminare. Per risolvere temporaneamente il problema, è possibile avviare il server remoto prima di fare clic sul pulsante Fine nella procedura guidata Nuovo server.
Se un file con estensione .war viene inserito nella cartella EarContent di un progetto EAR e non è definito come modulo Web nel file application.xml, l'applicazione enterprise non può essere pubblicata sul server e viene restituito il seguente messaggio di errore di esempio:
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0034E Impossibile aprire l'archivio nidificato "abc.war" in "D:\myworkspace\PublishEAR\EarContent"Tale errore si verifica perché il workbench non è in grado di gestire il file correttamente come modulo Web. Scegliere una delle seguenti soluzioni:
- Se il file è un modulo Web, aggiungerlo come modulo all'applicazione enterprise. Per informazioni dettagliate, consultare l'argomento relativo all'aggiunta di moduli a un'applicazione enterprise nella guida del prodotto.
- Se il file non è un modulo Web, modificare l'estensione file, ad esempio utilizzando .jar anziché .war
Per WebSphere Application Server V5.1 remoto o WebSphere Application Server V5.1 Express Edition remoto, se viene modificata la directory di distribuzione e la directory di pubblicazione nell'editor del server e l'applicazione viene nuovamente pubblicata, l' applicazione continua la pubblicazione sulla destinazione precedente. Di conseguenza, le modifiche alle directory di pubblicazione e distribuzione non vengono applicate. Tale problema si verifica quando si utilizza il metodo di copia locale o FTP.
La soluzione temporanea è riavviare il workbench. Le modifiche della configurazione per la directory di pubblicazione e la directory di distribuzione dovrebbero avere effetto.
Per un approccio più flessibile alla memorizzazione dei progetti, la tecnica per la pubblicazione delle applicazioni è stata modificata. Le applicazioni non vengono copiate prima di essere pubblicate sul server. Se l'applicazione è troppo grande, ad esempio se è superiore a 100 megabyte, l'operazione di copia utilizzata per il comando di pubblicazione impiegherà più tempo rispetto alla versione precedente. .
Attualmente, per questo problema non esiste alcuna soluzione temporanea. IBM® sta lavorando su un aggiornamento che consente di eliminare nella maggior parte dei casi la necessità di eseguire questa nuova operazione di copia.
Se viene avviato WebSphere Application Server v6.1 protetto e nell'editor del server viene modificato il tipo di connessione in RMI (Remote Method Invocation) o SOAP, dopo il salvataggio delle modifiche nell'editor del server potrebbe visualizzato il seguente messaggio di errore di pubblicazione:
La pubblicazione non viene eseguita poiché il server non è stato avviato. Avviare il server prima di eseguire l'operazione di pubblicazione.
È possibile ignorare senza problemi questo errore. In alternativa, quando lo stato del server nella vista Server appare come Avviato, è possibile completare il comando di pubblicazione (nella vista Server, fare clic con il pulsante destro del mouse sul server e selezionare Pubblica).
Quando si tenta di generare un'origine dati utilizzando la procedura guidata Creazione di origini dati e tabelle, è possibile che venga visualizzato un errore TargetInvocationException nella sezione Dettagli della finestra di dialogo Risultati della creazione tabelle e origini dati.
L'errore TargetInvocationException potrebbe verificarsi se viene impostato uno scambio progetti che contiene origini dati definite con lo stesso nome JNDI (Java Naming and Directory Interface).
Per risolvere temporaneamente l'errore, verificare che nel workbench sia già stata definita un'origine dati con lo stesso nome JNDI. In questo caso, rimuoverla dalla pagina Distribuzione dell'editor del descrittore di distribuzione e creare nuovamente l'origine dati utilizzando un nome JNDI diverso. Il nome JNDI deve essere univoco, in quanto costituisce un servizio di denominazione e ricerca utilizzato per collegare un bean enterprise a un'origine dati.
Quando si arresta il server dalla vista Server, il server potrebbe non arrestarsi completamente. La vista Server visualizza il server con stato Arrestato, ma il processo del server potrebbe non rispondere. Questa situazione in genere si verifica quando alcune risorse, ad esempio l'applicazione o il workbench, rimangono in sospeso su riferimenti a classi sul server. Di seguito vengono forniti alcuni scenari di esempio:
- Applicazioni in cicli indefiniti, o applicazioni in sospeso su riferimenti ad alcune classi sul server
- Applicazioni che effettuano la connessione al database Cloudscape o Derby senza ripulire la propria connessione
- Utilizzare il pulsante Verifica connessione nella procedura guidata Nuova connessione per aprire una connessione a un database Cloudscape o Derby senza scollegarsi dal database
Limitazione: non sono supportate più connessioni a un singolo database Cloudscape o Derby a causa di una limitazione della configurazione di Cloudscape o Derby. Se si gestisce la connessione del database da Database Explorer e un server tenta di effettuare un'altra connessione Cloudscape o Derby tramite un'origine dati, la seconda connessione sortisce esito negativo. Di conseguenza, per consentire a un server di stabilire una connessione al database Cloudscape o Derby è necessario chiudere la connessione da Database Explorer.
Soluzione temporanea: utilizzare le funzioni del sistema operativo per arrestare il processo java su cui è in esecuzione il server. In alternativa, è possibile riavviare il workbench per forzare il rilascio del riferimento. Per l'ultimo scenario di esempio descritto al terzo punto, è possibile utilizzare la vista Database Explorer per collegarsi e scollegarsi dal database Cloudscape o Derby.
È possibile che quando vengono pubblicate risorse sul server, ad esempio un enterprise bean, e si utilizza UTC (Universal Test Client) per verificare un EJB, il file JAR viene bloccato e non può essere aggiornato. Per questo motivo le modifiche effettuate nella strumentazione non vengono applicate durante la verifica dell' EJB. Una volta che UTC carica il file JAR EJB, il file JAR resta bloccato finché l'applicazione non viene rimossa e nuovamente aggiunta, o finché non viene riavviato il server.
Soluzione temporanea: utilizzare UTC nell'ambiente di sviluppo in cui le risorse dell'applicazione vengono eseguite al di fuori dello spazio di lavoro e non sul server. Per configurare questo tipo di esecuzione, utilizzare la procedura guidata Nuovo server oppure, in un secondo momento, utilizzare l'editor del server selezionando Esegui server con risorse nello spazio di lavoro nelle opzioni di pubblicazione. Ciò consente di aggiornare singoli file del progetto EJB senza dover sostituire l'intero file JAR EJB.
Dopo la verifica completa, l'applicazione può essere pubblicata sul server utilizzando l'opzione di pubblicazione Esegui su server con risorse su server.