© Copyright International Business Machines Corporation 2006. Všechna práva vyhrazena. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM® Corp.
Volba Minimalizovat aplikační soubory kopírované na server je podporována serverem WebSphere® Application Server 6.0.2.5 a novějším. V editoru serveru WebSphere Application Server V6.0 je zaškrtávací políčko pro danou volbu; volba se ignoruje, pokud je vybrána pro server dřívější než verze 6.0.2.5.
Pokud je modul EJB (Enterprise JavaBean) sdílen mezi více projekty EAR, které běží na serveru WebSphere Application Server, a jeden z projektů EAR je ze serveru odstraněn, další projekty EAR se musí restartovat, než budou moci přistoupit ke zdrojům, jako jsou objekty bean EJB v projektu EJB.
Pokud tuto akci neprovedete, možná uvidíte chybové zprávy podobné té níže zobrazené. Tyto chyby se dějí, protože názvy JNDI (Java Naming and Directory Interface) v projektu EJB jsou odebrány ze serveru, když se odebere EAR.
Zde je ukázková chybová zpráva:
00000028 SystemOut O javax.naming.NameNotFoundException: Context: myCell/nodes/myNode/servers/server1, name: ejb/ejbs/Session20Home: První komponenta v názvu Session20Home nenalezena. [Kořenová výjimka je org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
na com.ibm.ws.naming.jndicos.CNContextImpl.processNotFoundException(CNContextImpl.java:4730)
na com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1907)
na com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1862)
na com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1552)
na com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.java:1354)
na com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:172)
na javax.naming.InitialContext.lookup(InitialContext.java:363)
na com.ibm.ivj.ejb.runtime.AbstractAccessBean.lookupAndCacheHome(AbstractAccessBean.java:224)
na com.ibm.ivj.ejb.runtime.AbstractAccessBean.getGlobalHome(AbstractAccessBean.java:216)
na com.ibm.ivj.ejb.runtime.AbstractAccessBean.getHome(AbstractAccessBean.java:249)
na ejbs.Session20AccessBean.ejbHome(Session20AccessBean.java:50)
na ejbs.Session20AccessBean.instantiateEJB(Session20AccessBean.java:80)
na ejbs.Session20AccessBean.foo(Session20AccessBean.java:91)
Z důvodu různého chování a interakcí mezi běhovými prostředími Eclipse a WebSphere existují zvláštní kroky, které se požadují při zpracování klientů aplikací WebSphere s podporou podprocesů s pomocí dialogového okna Konfigurace spuštění klienta aplikace. Dialogové okno konfigurace spuštění klienta aplikace je dostupné z perspektivy J2EE, když vyberete Spustit > Spustit... v panelu nástrojů produktu. Pokud klient používá více podprocesů nebo používá základní struktury, které mohou používat další podprocesy, jako je Swing, pak musíte provést následující dodatečné kroky:
- V dialogovém okně konfigurace spuštění klienta aplikace vyberte kartu Argumenty. V textovém okně Argumenty VM uveďte následující parametr:
-Dosgi.noShutdown=true- Ujistěte se, že klientská aplikace zavolá System.exit()
Pokud nesplníte tyto podmínky, možná uvidíte problémy související se zavedením tříd nebo s JVM (Java™ virtual machine), které se neukončí po dokončení aplikace.
Předpokládá se, že máte projekt, například Projekt klienta aplikace, s následující konfigurací:
- fazeta projektu pro Javu je nastavena na verzi 1.4
- cílová běhová komponenta serveru pro tento projekt má volbu nahrazení horké metody povolenu na konfiguraci serveru
Možná se vám stane, že tlačítko Obnovit v pohledu Ladění nebude řádně fungovat. Například, když spustíte aplikaci na serveru v režimu ladění, pokusíte se změnit zdroj na běhové komponentě a pak použijete tlačítko Obnovit, abyste pokračovali v ladění aplikace. Možná se vám stane, že změny nahrazení horkou metodou ve zdrojovém kódu nebudou použity.
Pokuste se dvakrát klepnout na tlačítko Obnovit, abyste umožnili provedení změn běhové komponenty.
Pozn.: Tento problém nenastane, pokud nastavíte fazetu projektu pro Javu na verzi 5.0.
Tlačítko Odstranit v dialogovém okně Spravovat sdílené servery WebSphere nefunguje správně.
Rada: Chcete-li otevřít dialogové okno Spravovat sdílené servery WebSphere:
- V panelu nástrojů vyberte Okno > Předvolby. Otevře se dialogové okno Předvolby.
- V levém podokně vyberte Server > WebSphere > WebSphere v51.
- V pravém podokně, vedle pole Sdílené servery WebSphere, klepněte na tlačítko Spravovat. Otevře se dialogové okno Spravovat servery WebSphere.
Pokud použijete tlačítko Odstranit, server vypadá jako odstraněný. Avšak, když zavřete dialogové okno, znovu jej otevřete a obnovíte informace o vzdálených serverech, dříve odebraný server zůstane v dialogovém okně.
Abyste problém vyřešili, můžete ručně odstranit záznam o sdíleném serveru provedením následujících kroků:
- Otevřete soubor id.txt, který je umístěn v následujícím adresáři:
<directory>/plugins/com.ibm.etools.websphere.tools*/properties
kde <directory> je instalační adresář řadiče agentů.- Odstraňte záznam odkazující na sdílený server, který chcete odstranit.
- Odstraňte adresář implementace WebSphere, který byl uveden pro konkrétní sdílený server během vytváření serveru a všech jeho podadresářů. Příklady podadresářů pro odstranění v adresáři implementace WebSphere jsou: config, installedApps, temp, a jakékoli další adresáře a soubory umístěné v tomto adresáři.
- V dialogovém okně Spravovat sdílené servery WebSphere uveďte název hostitele a klepněte na tlačítko Obnovit, abyste ověřili, že jste úspěšně odstranili sdílený server.
Pokud máte další servery, jako je IBM HTTP Server, nainstalované ve stejném profilu WebSphere Application Server v6.x, stránka Nastavení serveru WebSphere průvodce novým serverem nemusí nalézt správná čísla portů RMI (remote method invocation) nebo SOAP. Dále se možná nenačte číslo portu administrativní konzoly.
Pokud průvodce novým serverem nemůže nalézt skutečná čísla portů definovaná pro server, je jeho předvoleným chováním předvyplnit pole portů předvolenými čísly portů: 2809 pro RMI a 8880 pro SOAP.
V případě definování nesprávných čísel portů se možná setkáte s následujícími problémy:
- Nelze se připojit k novému serveru, takže se nemůže server spustit ani zastavit.
- Nelze otevřít administrativní konzolu z tohoto nového serveru, důsledkem je možnost přijetí chyby nedefinovaných portů administrativní konzoly.
- Nelze spustit aplikace na tomto serveru, nefunguje příkaz Spustit na serverech.
Náhradní řešení:
- Zjistěte hodnoty portů konfigurovaného profilu odkázáním se na soubory konfigurace serveru. Hodnoty portů jsou uloženy v souboru serverindex.xml umístěném v následujícím adresáři:
<directory>\profiles\<profileName>\config\cells\<cellName>\nodes\<nodeName>, kde <directory> je adresář instalace serveru WebSphere Application Server.
Použijte soubor serverindex.xml k vyplnění níže uvedené tabulky pro určení skutečných čísel portů definovaných pro server:
Název portu Popis portu Předvolené číslo portu Přiřazené číslo portu SOAP_CONNECTOR_ADDRESS SOAP 8880 BOOTSTRAP_ADDRESS RMI 2809 WC_adminhost Administrativní konzola 9060 WC_defaulthost HTTP transport 9080 - Pro připojení k serveru uveďte správné číslo portu RMI nebo SOAP, když vytvoříte server.
- Pro spuštění administrativní konzoly použijte externí webový prohlížeč a zadejte do pole s adresou adresu URL, abyste opravili port administrativní konzoly:
http://<název_počítače>:<WC_adminhost>/IBM/console
Např.: http://localhost:9060/IBM/console- Chcete-li spustit aplikace na serveru, vydejte příkaz Spustit na serveru. Když se otevře webový prohlížeč, opravte adresu URL číslem přenosového portu HTTP definovaného pro váš server.
http://<název_počítače>:<WC_předv_host>/<ContextRoot>/<úvodní_stránka_aplikace>
Např.: http://localhost:9080/MyApplication/index.jsp
Pozn.: Servery automaticky definované v pohledu Servery nemusí odkazovat na správná čísla portů pro skutečný server. V tomto případě použijte stejné výše uvedené náhradní řešení.
Nástroj Správa profilů je nástroj serveru WebSphere Application Server, který vytvoří profil pro každé běhové prostředí. Můžete použít pracovní prostředí pro spuštění nástroje Správa profilů serveru WebSphere Application Server. Avšak nástroj Správa profilů nefunguje pod 64bitovým procesorem, místo toho použijte nástroj příkazového řádku manageprofiles poskytovaný serverem WebSphere Application Server.
Pokud v operačních systémech Windows používáte port RMI (remote method invocation) pro připojení k serveru WebSphere Application Server v6.x, můžete se setkat s dlouhými prodlevami při zavádění připojení k serveru po ztrátě síťové připojitelnosti. To může nastat, i když je server lokální a síťová připojitelnost se ztratí pouze dočasně, což je běžné v bezdrátovém síťovém prostředí.
Pokud víte, že server je spuštěn, ale stav v pohledu Servery zobrazuje Zastaven nebo Spouštění, zkuste zjistit, zda můžete navázat spojení se serverem přepnutím připojení serveru z RMI na SOAP. Stav serveru by se měl změnit na Spuštěný.Existuje několik voleb, které jsou dostupné pro navázání spojení se serverem v bezdrátovém síťovém prostředí:
- Nejsnadnější a nejbezpečnější volba je přepnout připojení na použití portu SOAP. Po ztrátě síťové propojitelnosti mají připojení SOAP schopnost napravit se rychleji ve srovnání s připojením RMI.
- Pokud musíte použít připojení RMI, můžete se pokusit upravit předvolené nastavení týkající se ukládání do mezipaměti DNS (Domain Name System) v operačním systému Windows. Podrobnosti viz následující článek podpory Microsoft:
http://support.microsoft.com/kb/318803
Operační systém Windows má v ukládání do mezipaměti DNS sestavení, které udržuje názvy hostitelů. To umožňuje rychlejší obrat při vydávání vyhledání DNS. Avšak nevýhodou je, pokud selže vyhledání DNS. Operační systém Windows uloží do mezipaměti špatnou hodnotu na předvolenou dobu 300 vteřin. Takže i když server DNS může o něco později vyhledání analyzovat, ve skutečnosti se nepokusí o vyhledání, dokud neuplyne doba uložení do mezipaměti. V důsledku toho může neúspěšné vyhledání DNS s předvoleným nastavením trvat až 5 minut, než se skutečně provede nový pokus ve vyhledání. Nastavení doby uložení do mezipaměti na 0 vteřin vynutí, že operační systém Windows nikdy neuloží vyhledávací dotazy DNS, které selhaly, a umožní výskyt opakovaného připojení, jakmile bude DNS k dispozici.
Následuje příklad zákazu ukládání do mezipaměti DNS pro neúspěšná vyhledání na operačních systémech Windows:
Do následujícího klíče registru: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Přidejte jednu z následujících hodnot registru:
- Pro Windows XP/2003:
"MaxNegativeCacheTtl"=dword:00000000- Pro Windows 2000:
"NegativeCacheTime"=dword:00000000
Opakované publikování aplikace, restartování aplikace nebo odinstalování a opakovaná instalace aplikace nejsou dostatečné akce pro použití různých změn zdrojů definovaných na stránce Implementace editoru Deskriptor implementace aplikací na serveru. Změna názvu databáze zdroje dat na stránce Implementace editoru je známá změna, kterou server nezachytí, a může existovat několik dalších změn, které server nezachytí.
Jako náhradní řešení proveďte následující kroky, abyste použili změny na serveru:
- Zastavte server.
- V pohledu Servery klepněte pravým tlačítkem myši na server a vyberte Zastavit.
- V pohledu Servery počkejte, až stav serveru zobrazí Zastavený a pak pokračujte na další krok.
- Spusťte pracovní prostředí.
POZN.: Pokud selže spuštění serveru, je třeba použít funkce z operačního systému pro zastavení procesu javy, kde je server spuštěn. Jinak můžete restartovat pracovní prostředí a pak se pokusit spustit server znovu.- Spusťte server.
- V pohledu Servery klepněte pravým tlačítkem myši na server a vyberte Spustit.
- V pohledu Servery počkejte na dokončení opakovaného publikování a až stav serveru a aplikace zobrazí Spuštěný a pak pokračujte na další krok.
- Spusťte aplikaci na serveru, použijte například příkaz Spustit na serveru. Ve výsledku by měl být server nyní schopen zachytit změny z editoru Deskriptor implementace aplikací.
Pokud přidáte soubor JAR utility do webových knihoven webového projektu a odkážete na třídy uvnitř souboru JAR v kódu, možná obdržíte chybu java.lang.NoClassDefFoundError, když se pokusíte spustit aplikaci na serveru.
Náhradním řešením je po přidání souboru JAR utility do modulu EAR přidat soubor JAR do závislostí modulů J2EE webového projektu dokončením následujících kroků:
- Přidejte soubor JAR utility do modulu EAR. Podrobnosti viz téma Přidání souborů JAR utility projektu v nápovědě produktu.
- Klepněte pravým tlačítkem myši na webový projekt a vyberte Vlastnosti. Otevře se dialogové okno Vlastnosti.
- Vyberte Závislosti modulů J2EE.
- Na kartě Moduly J2EE pod sloupcem JAR/Modul vyberte zaškrtávací políčko u vašeho souboru JAR utility.
Pokud server WebSphere Application Server V6.1 běží na zabezpečeném připojení SOAP, další zabezpečené připojení SOAP k serveru WebSphere Application Server V6.0 selže. Stejný problém nastane i naopak, když server WebSphere Application Server V6.0 spuštěný na zabezpečeném připojení SOAP způsobí selhání zabezpečeného připojení SOAP k serveru WebSphere Application Server V6.1. Avšak problém nenastane, pokud je server definován v pohledu Servery a jeho stav je prázdný.
Náhradním řešením je použít zabezpečené připojení RMI (remote method invocation) se serverem, namísto připojení SOAP, nebo použít nezabezpečené připojení SOAP.
Pokud je zastaven vzdálený server, dokončení průvodce novým serverem může trvat dlouho poté, co klepnete na tlačítko Dokončit. Náhradním řešením je spustit vzdálený server, než klepnete na tlačítko Dokončit v průvodci novým serverem.
Pokud je soubor s příponou .war umístěn ve složce EarContent projektu EAR a není definován jako webový modul v application.xml, podniková aplikace selže při publikování na server s následující ukázkovou chybovou zprávou:
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0034E Nelze otevřít vložený archiv "abc.war" v "D:\myworkspace\PublishEAR\EarContent"Příčinou této chyby je, že pracovní prostředí nemůže obsloužit soubor správně jako webový modul. Vyberte jedno z následujících náhradních řešení:
- Pokud je soubor webový modul, přidejte soubor jako modul k podnikové aplikaci. Další informace viz téma Přidání modulů do podnikové aplikace v nápovědě k produktu.
- Pokud soubor není webový modul, návrhem na náhradní řešení problému s publikováním je změnit příponu souboru na jinou příponu než .war, například na .jar
Pokud pro vzdálený WebSphere Application Server V5.1 nebo vzdálený WebSphere Application Server V5.1 Express Edition změníte adresář implementace a adresář publikování v editoru serveru a pak znovu publikujete aplikaci, aplikace bude pokračovat v publikování na předchozí místo určení. Ve výsledku se změny v adresářích publikování a implementace nepoužijí. Tento problém se vyskytne, když použijete lokální kopii nebo metody FTP.
Náhradním řešením je restartovat pracovní prostředí. Ve výsledku by se měly změny konfigurace adresáře publikování a adresáře implementace použít.
Pro podporu flexibilnějšího přístupu k ukládání projektů se změnila technika pro publikování aplikací. Aplikace se nyní zkopírují, než se publikují na serveru. Pokud je aplikace velká, například větší než 100 megabajtů, tato operace kopírování použitá pro příkaz publikování bude trvat déle oproti tomu, s čím jste se setkali v předchozí verzi.
Momentálně neexistuje žádné náhradní řešení. IBM pracuje na aktualizaci, která eliminuje potřebu provádění této nové operace kopírování pro většinu případů.
Pokud je spuštěn server WebSphere Application Server v6.1 a v editoru serveru změníte typ připojení serveru na RMI (remote method invocation) nebo SOAP, možná uvidíte následující chybovou zprávu o selhání publikování poté, co uložíte změny v editoru serveru:
Publikování se neprovede, protože server není spuštěn. Spusťte server, než provedete operaci publikování.
Můžete chybu bezpečně ignorovat. Volitelně, až bude stav serveru v pohledu Servery Spuštěný, můžete dokončit příkaz pro publikování (v pohledu Servery klepněte pravým tlačítkem myši na server a vyberte Publikovat).
Když se pokusíte generovat zdroj dat s pomocí průvodce Tvůrce zdrojů dat a tabulek, můžete zaznamenat chybu TargetInvocationException v sekci Podrobnosti dialogového okna Výsledky vytváření zdrojů dat a tabulek.
Příčina chyby TargetInvocationException se může vyskytnout, když importujete výměnu projektů, která obsahuje zdroje dat definované se stejným názvem JNDI (Java Naming and Directory Interface).
Náhradním řešením chyby TargetInvocationException je ověření, zda je zdroj dat se stejným názvem JNDI již definován v pracovním prostředí. Je-li tomu tak, odstraňte jej ze stránky Implementace editoru Deskriptor implementace aplikací a pak znovu vytvořte zdroj dat s pomocí jiného názvu JNDI. Název JNDI musí být jedinečný, protože je to služba pojmenování a vyhledání, která se používá ke svázání objektu enterprise bean se zdrojem dat.
Při zastavení serveru z pohledu Servery nemusí být server zcela zastaven. Pohled Servery zobrazuje Zastavený, ale zpracování serveru může být ve stavu, kdy neodpovídá. To obvykle nastane, když artefakt, jako je aplikace nebo pracovní prostředí, udržuje reference na třídy na serveru. Následují příklady scénářů:
- Aplikace, které jsou v nekonečných smyčkách, nebo aplikace udržující reference na některé třídy na serveru.
- Aplikace, které tvoří připojení databáze Cloudscape nebo Derby, bez vyčištění připojení
- Použití tlačítka Test připojení v průvodci novým připojením datových nástrojů pro otevření připojení k databázi Cloudscape nebo Derby bez odpojení z databáze
Omezení: Více připojení k jedné databázi Cloudscape nebo Derby není podporováno kvůli omezením konfigurace Cloudscape nebo Derby. Pokud udržujete připojení k databázi z průzkumníka databáze a server se pokusí vytvořit jiné připojení k databázi Cloudscape nebo Derby přes zdroj dat, druhé připojení selže. Ve výsledku je třeba uzavřít připojení z průzkumníka databáze, než bude server moci zavést připojení k databázi Cloudscape nebo Derby.
Jako náhradní řešení problému je třeba použít funkce z operačního systému pro zastavení procesu javy, kde je server spuštěn. Jinak můžete restartovat pracovní prostředí pro vynucení uvolnění odkazu. Poslední jednoduchý scénář je popsán ve třetím bodě, můžete použít pohled Průzkumník databáze pro připojení a odpojení od databáze Cloudscape nebo Derby.
Je možné, že pokud publikujete prostředky na server, například objekt enterprise bean, a použijete UTC (Universal Test Client) pro testování EJB, soubor JAR se uzamkne a nelze jej aktualizovat. Ve výsledku nebude možné zachytit provedené změny v nástrojích během testování EJB. Když UTC zavede soubor JAREJB, soubor JAR zůstane uzamčen, dokud se aplikace neodstraní a znovu nepřidá, nebo dokud se server nerestartuje.
Náhradní řešení je použít UTC v prostředí vývoje, kde prostředky aplikací běží mimo pracovní prostředí a neběží na serveru. To lze nakonfigurovat s pomocí průvodce novým serverem nebo později změnit s pomocí editoru serveru výběrem Spustit server s prostředky v pracovním prostředí pod volbami Publikování. To umožní aktualizaci jednotlivých souborů v projektu EJB bez požadování úplné náhrady celého souboru EJB JAR.
Po úplném testování aplikace ji lze publikovat na server s pomocí volby pro publikování Spustit server s prostředky na serveru.