© 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 la IBM® Corp.
L'opzione Riduci i file dell'applicazione copiati sul server viene supportata da WebSphere® Application Server 6.0.2.5 e successive. Nell'editor del server WebSphere Application Server V6.0, vi è una casella di spunta per l'opzione; l'opzione viene ignorata se viene selezionata per i server precedenti alla versione 6.0.2.5.
Se un modulo EJB (Enterprise JavaBean) viene condiviso tra più progetti EAR in esecuzione su un WebSphere Application Server ed uno dei progetti EAR viene rimosso dal server, altri progetti EAR devono essere riavviati prima che possano accedere alle risorse, quali i bean EJB, nel progetto EJB.
Se non si effettua questa operazione, si potrebbero visualizzare degli errori simili a quello seguente. Tali errori si verificano perché il nome JNDI (Java Naming and Directory Interface) nel progetto EJB viene rimosso dal server quando viene rimosso EAR.
Viene riportato un messaggio di errore di esempio:
00000028 SystemOut O javax.naming.NameNotFoundException: Contesto: myCell/nodes/myNode/servers/server1, nome: ejb/ejbs/Session20Home: Primo componente nel nome Session20Home non trovato. [Eccezione root 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 dei diversi funzionamenti e interazioni tra gli ambienti di runtime di Eclipse e WebSphere, vi sono dei passi aggiuntivi richiesti durante l'esecuzione dei WebSphere Application Client a più thread tramite la finestra di dialogo delle configurazioni di avvio del client delle applicazioni. La finestra di dialogo delle configurazioni di avvio del client di applicazioni è disponibile dalla prospettiva J2EE quando si seleziona Esegui > Esegui... nella barra degli strumenti del prodotto. Se il proprio client utilizza più thread, oppure utilizza i framework che potrebbero utilizzare ulteriori thread come Swing, sarà necessario completare i seguenti passi aggiuntivi:
- Nella finestra di dialogo Configurazioni di avvio del client delle applicazioni, selezionare la scheda Argomenti. Nella casella di testo Argomenti VM specificare il seguente parametro:
-Dosgi.noShutdown=true- Verificare che l'applicazione del client richiami System.exit()
Se non vengono specificati, si potrebbero verificare dei problemi correlati al caricamento delle classi oppure alle JVM (Java™ virtual machines) che non terminano una volta completata l'esecuzione dell'applicazione.
Si supponga di avere un progetto, ad esempio un progetto del client delle applicazioni, con le seguenti configurazioni:
- il facet progetto per Java viene impostato sulla versione 1.4
- Il runtime del server di destinazione per questo progetto ha l'opzione della sostituzione del metodo hot abilitata nella configurazione del proprio server
Potrebbe accadere che il pulsante Ripristina nella vista Debug non funzioni correttamente. Ad esempio, quando si esegue l'applicazione sul server in modalità debug, provare a modificare l'origine al runtime, quindi utilizzare il pulsante Ripristina per continuare il debug della propria applicazione. Si potrebbe verificare che le modifiche di sostituzione del metodo hot al codice di origine non vengano applicate.
Provare a fare clic due volte sul pulsante Ripristina per consentire alle modifiche di diventare effettive.
Nota: tale problema non si verifica quando si imposta il facet del progetto per la versione 5.0 di Java.
Il pulsante Rimuovi sulla 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 pannello di sinistra, selezionare Server > WebSphere > WebSphere v51.
- Sul pannello di destra, accanto al campo Server WebSphere condivisi, fare clic sul pulsanteGestisci. Si apre la finestra di dialogo Gestisci server WebSphere condivisi.
Se si utilizza il pulsante Rimuovi, il server appare come rimosso. Tuttavia, se si esce dalla finestra di dialogo, aprirla nuovamente e aggiornare le informazioni del server remoto, il server remoto rimosso precedentemente si trova ancora nella finestra di dialogo.
Per risolvere temporaneamente il problema, è possibile rimuovere manualmente la voce del server condiviso completando i seguenti passi:
- Aprire il file id.txt che si trova nella seguente directory:
<directory>/plugins/com.ibm.etools.websphere.tools*/properties
dove<directory> installazione di Agent Controller.- Eliminare la voce che fa riferimento al server condiviso che si desidera rimuovere.
- Rimuovere la directory della distribuzione WebSphere specificata per quel particolare server condiviso durante la creazione del server e tutte le sue directory secondarie. Degli esempi di directory secondarie da rimuovere nella directory di distribuzione WebSphere sono: config, installedApps, temp equalsiasi altra directory e file che si trovino in tale directory.
- Nella finestra di dialogo Gestisci server WebSphere condivisi, specificare un nome host e fare clic sul pulsante Aggiorna per verificare che sia stato rimosso il server con successo.
Se si hanno server aggiuntivi, come IBM HTTP Server, installati all'interno dello stesso profilo WebSphere Application Server v6.x, la pagina delle impostazioni del server WebSphere della procedura guidata Nuovo server potrebbe non individuare i numeri di porta corretti per RMI (remote method invocation) o SOAP. Inoltre, il numero della porta per la console di gestione potrebbe non essere richiamato.
Quando la procedura guidata Nuovo server non riesce ad individuare i numeri della porta definiti per un server, il suo funzionamento predefinito è quello di riempire i campi con i numeri delle porte predefiniti: 2809 per RMI e 8880 per SOAP.
Nel caso in cui vengono definiti i numeri delle porte non corrette, si potrebbe verifica i seguenti problemi:
- Impossibile connettersi al nuovo server, per avviare o arrestare il server.
- Impossibile aprire la console di gestione da questo nuovo server, come risultato si potrebbe ricevere un errore di porta della console di gestione non definito.
- Impossibile eseguire le applicazioni su questo server, come il comando Esegui su server che non funziona
Soluzione temporanea :
- Stabilire i valori delle porte di un profilo configurato facendo riferimento ai suoi file di configurazione. I valori della porta 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 riempire la tabella per stabilire i numeri reali delle porte definite per il server:
Nome porta Descrizione della porta Numero porta predefinito Il numero porta assegnato SOAP_CONNECTOR_ADDRESS SOAP 8880 BOOTSTRAP_ADDRESS RMI 2809 WC_adminhost Console di gestione 9060 WC_defaulthost Trasporto HTTP 9080 - Per connettersi al server, specificare il numero corretto della porta per RMI o per SOAP quando si crea il server.
- Per avviare la console di gestione, utilizzare un browser Web esterno ed immettere nel campo dell'indirizzo l'URL per la porta corretta della console di gestione:
http://<nome_computer>:<WC_adminhost>/IBM/console
Ad esempio: http://localhost:9060/IBM/console- Per eseguire le applicazioni sul server, eseguire un comando Esegui su server. Quando si apre il browser Web, correggere l'URL con il numero della porta del trasporto HTTP definito per il proprio server.
http://<nome_computer>:<WC_defaulthost>/<RootContesto>/<pagina_avvio_applicazione>
Ad esempio: http://localhost:9080/MyApplication/index.jsp
Nota: i server definiti automaticamente nella vista Server potrebbero non fare riferimento ai numeri delle porte corrette del vero server. Se così fosse, utilizzare la stessa soluzione temporanea illustrata precedentemente.
Lo strumento di gestione profili è uno strumento di WebSphere Application Server che crea i profili per ciascun ambiente di runtime. È possibile utilizzare i workbench per avviare lo strumento di gestione profili di WebSphere Application Server. Tuttavia, lo strumento di gestione profili non funziona in un processore a 64 bit, utilizzare quindi, lo strumento della riga comandi manageprofiles fornito con WebSphere Application Server.
Sui sistemi operativi Windows, se si sta utilizzando la porta RMI (remote method invocation)per connettersi al proprio WebSphere Application Server v6.x, si potrebbero verificare dei lunghi ritardi nello stabilire una connessione al server dopo aver perso la connettività con la rete. Ciò si può verificare anche se il server è locale e la connettività di rete viene persa temporaneamente, problema comune in un ambiente di rete wireless.
Se si è certi che il server è stato avviato, ma lo stato nella vista Server visualizza Arrestato o In avvio, provare a stabilire una connessione al server cambiando la connessione al server da RMI a SOAP. Lo stato del server dovrebbe essere modificato in Avviato.Vi sono un paio di opzioni disponibili per stabilire la connessione ad un server in un ambiente di rete wireless:
- L'opzione più semplice e sicura, è quella di cambiare la connessione per utilizzare la porta SOAP. Dopo aver perso la connettività di rete, le connessioni SOAP hanno la capacità di recuperare più rapidamente rispetto alla connessione RMI.
- Se fosse necessario utilizzare una connessione RMI, è possibile provare a modificare le impostazioni predefinite relative al DNS (Domain Name System) che memorizza nella cache sui sistemi operativi Windows. Per i dettagli, fare riferimento al seguente articolo di supporto Microsoft:
http://support.microsoft.com/kb/318803
Il sistema operativo Windows ha una memorizzazione nella cache DNS integrata che mantiene i nomi degli host risolti. Ciò consente dei tempi di risposta più rapidi quando si effettuano delle ricerche del DNS. Tuttavia, vi è uno svantaggio, se la ricerca del DNS non riesce. Il sistema operativo Windows memorizza nella cache il valori non riusciti, per un tempo predefinito di 300 secondi. Pertanto, anche se il server DNS riesce a risolvere la ricerca immediatamente dopo, non prova ad effettuare la ricerca fino a quando il tempo della cache non scade. Come risultato si ha che una ricerca del DNS non riuscita con le impostazioni predefinite, può impiegare 5 minuti prima che un nuovo tentativo di ricerca venga effettuato. Impostando il tempo della cache su 0 secondi, si forzerà il sistema operativo Windows a non memorizzare mai nella cache le query di ricerca del DNS non riuscite, e consente il ripristino della connessione non appena il DNS diventa disponibile.
Quello che segue è un esempio di disattivazione della memorizzazione nella cache per le ricerche non riuscite sui 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
Ripubblicare l'applicazione, riavviare l'applicazione o disinstallare e reinstallare l'applicazione non sono operazioni sufficienti per applicare una varietà di modifiche alle risorse definite nella pagina distribuzione dell'editor del descrittore di distribuzione dell'applicazione sul server. Una modifica al nome del database di un'origine dati nella pagina Distribuzione dell'editor è una modifica nota che il server non riesce a rilevare, vi potrebbero essere diverse altre modifiche che il server non riesce a rilevare.
Come risoluzione temporanea, completare i seguenti passi per applicare le modifiche sul server:
- Arrestare il server.
- Nella vista Server, fare clic con il tasto destro del mouse sul server e selezionare Arresta.
- Nella vista Server, attendere che lo stato visualizzato del server diventi Arrestato e poi continuare con il passo successivo.
- Avviare il workbench.
NOTA: se non si riesce ad avviare il server, è necessario utilizzare le funzioni del sistema operativo per arrestare il processo java sul quale il server è in esecuzione. In alternativa, è possibile riavviare il workbench e poi riprovare ad avviare nuovamente il server.- Avviare il server.
- Nella vista Server, fare clic con il tasto destro del mouse sul server e selezionare Avvia.
- Nella vista Server, attendere che la ripubblicazione venga completata e lo stato visualizzato del server e dell'applicazione diventi Avviato e poi continuare con il passo successivo.
- Eseguire l'applicazione sul server, ad esempio utilizzare il comando Esegui sul server. Come risultato, il server dovrebbe essere in grado di rilevare le modifiche dall'editor del descrittore di distribuzione dell'applicazione.
Se si aggiunge un file JAR del programma di utilità alle librerie Web per un progetto Web e si fa riferimento alle classi all'interno del file JAR nel proprio codice, potrebbe verificarsi un errore java.lang.NoClassDefFoundError quando si prova ad eseguire l'applicazione sul server.
La soluzione temporanea è, dopo aver aggiunto un file JAR al programma di utilità al modulo EAR, quella di aggiungere il file JAR alle dipendenze dei moduli J2EE del progetto Web, completando i seguenti passi:
- Aggiungere un file JAR al programma di utilità al modulo EAR. Consultare il documentoAggiunta di file JAR del programma di utilità del progetto nella guida del prodotto per ulteriori dettagli.
- Fare clic con il tasto destro del mouse sul progetto Web e selezionare Proprietà. Si apre la finestra di dialogo Proprietà.
- Selezionare Dipendenze dei moduli J2EE.
- Nella scheda Moduli J2EE nella colonna JAR/Modulo, selezionare la casella di controllo affianco al proprio file JAR del programma di utilità.
Se un WebSphere Application Server V6.1 è in esecuzione su una connessione SOAP protetta, un'altra connessione SOAP protetta ad un WebSphere Application Server V6.0 non verrà eseguita correttamente. Lo stesso problema si verifica nell'ordine inverso, nel caso di un WebSphere Application Server V6.0 in esecuzione su una connessione SOAP protetta fa si che una connessione SOAP protetta ad un WebSphere Application Server V6.1 non venga completata correttamente. Tuttavia, il problema non si verifica se il server viene definito nella vista Server è il suo stato è vuoto.
La soluzione temporanea consiste nell'utilizzare una connessione RMI (remote method invocation) protetta al server invece che una connessione SOAP, oppure utilizzare una connessione SOAP non protetta.
Se il server remoto viene arrestato, la procedura guidata Nuovo server potrebbe impiegare molto tempo per terminare dopo aver fatto clic sul pulsante Fine. Una soluzione temporanea può essere quella di avviare il server remoto prima di fare clic sul pulsante Fine nella procedura guidata Nuovo server.
Se un file con un'estensione .war viene collocato nel EarContent di un progetto EAR e non è definito come un modulo Web in application.xml, l'applicazione enterprise non riesce a pubblicare sul server con 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"La causa di questo errore sta nel workbench che non è in grado di gestire il file correttamente come un modulo Web. Scegliere una delle seguenti soluzioni temporanee:
- Se il file è un modulo Web, aggiungere il file come un modulo all'applicazione enterprise. Per i dettagli, consultare il documentoAggiunta di moduli ad un'applicazione enterprise nella guida del prodotto.
- Se il file non un modulo Web, una possibile soluzione temporanea del problema della pubblicazione, consiste nel modificare l'estensione del file in un'estensione diversa da .war, ad esempio in .jar
Per un WebSphere Application Server V5.1 remoto o per un WebSphere Application Server V5.1 Express edition remoto, se si modifica la directory di distribuzione e la directory di pubblicazione nell'editor del server e poi si pubblica nuovamente l'applicazione, l'applicazione continua a pubblicare sulla precedente destinazione. Si avrà come risultato che le modifiche alle directory di pubblicazione e distribuzione non vengono applicate. Tale problema si verifica quando si utilizzano i metodi della copia locale o dell'FTP.
La soluzione temporanea consiste nel riavviare il workbench. Il risultato sarà che le modifiche alla configurazione per le directory di pubblicazione e distribuzione diventeranno effettive.
Per supportare un approccio più flessibile per salvare i progetti, la tecnica di pubblicazione delle applicazioni è stata modificata. Le applicazioni, ora vengono copiate prima di essere pubblicate sul server. Se l'applicazione è di gradi dimensioni, ad esempio maggiore di 100 megabyte, tale operazione di copia utilizzata per il comando di pubblicazione impiegherà un tempo maggiore, diversamente da quanto accadeva nella versione precedente.
Correntemente, non vi è una soluzione al problema. IBM sta lavorando su un aggiornamento che eliminerà la necessità di eseguire questa nuova operazione di copia nella maggior parte dei casi.
Se viene avviato un WebSphere Application Server v6.1 protetto e nell'editor del server si modifica il tipo di connessione del server nel RMI (remote method invocation) o SOAP, si potrebbe visualizzare il seguente messaggio di errore di pubblicazione dopo aver salvato le modifiche nell'editor del server:
La pubblicazione non viene eseguita fino a quando il server non viene avviato. Avviare il server prima di eseguire l'operazione di pubblicazione.
È possibile ignorare l'errore senza problemi. Facoltativamente, dopo che lo stato del server nella vista Server diventa Avviato, è possibile completare un comando di pubblicazione (nella vista Server, fare clic con il tasto destro del mouse e selezionare Pubblica).
Quando si prova a generare un'origine dati utilizzando la procedura guidata Creazione tabelle e origine dati, si potrebbe verificare un errore TargetInvocationException nella sezione Dettagli della finestra di dialogo Risultati della creazione tabelle e origine dati.
La causa dell'errore TargetInvocationException si potrebbe verificare se si importa uno scambio progetto che contiene le origini dati definite con lo stesso nome JNDI (Java Naming and Directory Interface).
Per risolvere temporaneamente l'errore TargetInvocationException, verificare se un'origine dati con lo stesso nome JNDI è stato già definito nel workbench. Se questo fosse il caso, rimuoverla dalla pagina Distribuzione dell'Editor del descrittore di distribuzione dell'applicazione e poi creare l'origine dati utilizzando un nome JNDI diverso. Il nome JNDI deve essere univoco, dato che si tratta di un servizio di denominazione e di ricerca, utilizzato per collegare un bean enterprise ad un'origine dati.
Quando si arresta il server dalla vista Server, il server potrebbe non essere arrestato completamente. La vista Server visualizza lo stato Arrestato ma il processo del server potrebbe essere in uno stato di non risposta. Ciò, normalmente si verifica quando le risorse quali la propria applicazione o il workbench resta sospeso sui riferimenti alle classi sul server. Quelli seguenti sono degli scenari di esempio:
- Applicazioni che si trovano in un ciclo ininterrotto, o applicazioni che restano sospese sui riferimenti a delle classi sul server
- Applicazioni che eseguono le connessioni al database Cloudscape o Derby senza eseguire il clean up della loro connessione
- Utilizzo del pulsante Verifica connessione nella procedura guidata Nuova connessione degli strumenti dati, per aprire una connessione al database Cloudscape o Derby senza disconnettersi dal database
Limitazione: non sono supportate più connessioni ad un singolo database Cloudscape o Derby a causa di una limitazione di configurazione di Cloudscape o Derby. Se si mantiene la connessione al database da Esplora database ed un server prova ad effettuare un'altra connessione a Cloudscape o Derby tramite un'origine dati, la seconda connessione non riuscirà. Come risultato, sarà necessario chiudere la connessione da Esplora database prima che un server possa stabilire una connessione al database Cloudscape o Derby.
Una soluzione temporanea al problema, consiste nel dover utilizzare le funzioni dal proprio sistema operativo per arrestare il processo java sul quale il server è in esecuzione. In alternativa, è possibile riavviare il workbench per forzare il rilascio del riferimento. Nell'ultimo scenario di esempio descritto nel terzo punto, è possibile utilizzare la vista Esplora database per connettersi e poi disconnettersi dal database Cloudscape o Derby.
È possibile che quando si pubblicano le risorse sul server, per esempio un bean, e si utilizza l'UTC (Universal Test Client) per verificare un EJB, il file JAR viene bloccato e non può essere aggiornato. Ciò avrà come risultato delle modifiche eseguite nella strumentazione che non vengono rilevate durante la verifica dell'EJB. Una volta che l'UTC carica il file JAR dell'EJB, il file JAR resta bloccato fino a che l'applicazione non viene rimossa e aggiunta nuovamente, oppure il server fino a quando il server non viene riavviato.
La soluzione temporanea è quella di utilizzare l'UTC nell'ambiente di sviluppo dove le risorse dell'applicazione vengono eseguite al di fuori dello spazio di lavoro e non vengono eseguite sul server. È possibile eseguire tale configurazione utilizzando la procedura guidata Nuovo Server, oppure può essere modificato successivamente, utilizzando l'editor del server selezionando Esegui server con risorse nell'area di lavoro nelle opzioni di pubblicazione. Ciò consente ai file singoli all'interno del progetto EJB di essere aggiornati senza richiedere una sostituzione dell'intero file JAR di EJB.
Una volta che l'applicazione è stata verificata completamente, può essere pubblicata sul server utilizzando l'opzione di pubblicazione Esegui server con risorse sul server.