© Copyright International Business Machines Corporation 2006. Minden jog fenntartva. Az USA kormányzati felhasználóinak jogkorlátozása: A használatot, a másolást és a nyilvánosságra hozatalt az IBM® Corporation vállalattal kötött GSA ADP Schedule Contract korlátozza.
A Kiszolgálóra másolt alkalmazásfájlok minimalizálása beállítást csak a WebSphere® Application Server 6.0.2.5 és újabb kiadásai támogatják. A WebSphere Application Server 6.0 kiszolgáló szeresztőjében van egy jelölőnégyzet ehhez a beállításhoz. A beállítást a rendszer figyelmen kívül hagyja, ha a 6.0.2.5 verziónál korábbi verziójú kiszolgálót választ ki.
Ha egy Vállalati JavaBean (EJB) modul WebSphere alkalmazáskiszolgálón futó több EAR projekt között van megosztva és az egyik EAR projekt eltávolításra kerül a kiszolgálóról, akkor a többi EAR projektet újra kell indítani ahhoz, hogy hozzáférjenek az EJB projektben található erőforrásokhoz, például az EJB komponensekhez.
Ha nem végzi el ezt a műveletet, akkor az alábbi hibaüzenethez hasonló hibaüzenetek jelenhetnek meg. Ezek a hibák azért történek, mert az EAR eltávolításakor az EAR projektben lévő Java JNDI név is eltávolításra kerül.
Példa a hibaüzenetre:
00000028 SystemOut O javax.naming.NameNotFoundException: Context: myCell/nodes/myNode/servers/server1, name: ejb/ejbs/Session20Home: A Session20Home név első komponense nem található. [A gyökér kivétel: org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
a com.ibm.ws.naming.jndicos.CNContextImpl.processNotFoundException(CNContextImpl.java:4730) helyen
a com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1907) helyen
a com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1862) helyen
a com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1552) helyen
a com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.java:1354) helyen
a com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:172) helyen
a javax.naming.InitialContext.lookup(InitialContext.java:363) helyen
a com.ibm.ivj.ejb.runtime.AbstractAccessBean.lookupAndCacheHome(AbstractAccessBean.java:224) helyen
a com.ibm.ivj.ejb.runtime.AbstractAccessBean.getGlobalHome(AbstractAccessBean.java:216) helyen
a com.ibm.ivj.ejb.runtime.AbstractAccessBean.getHome(AbstractAccessBean.java:249) helyen
a ejbs.Session20AccessBean.ejbHome(Session20AccessBean.java:50) helyen
a ejbs.Session20AccessBean.instantiateEJB(Session20AccessBean.java:80) helyen
a ejbs.Session20AccessBean.foo(Session20AccessBean.java:91) helyen
Az Eclipse és WebSphere futási környezetek közötti különböző viselkedések és együttműködések miatt további lépéseket kell végrehajtani a többszálas WebSphere alkalmazás ügyfelek Alkalmazásügyfél indítási konfiguráció párbeszédablakon keresztüli indításakor. Az Alkalmazásügyfél indítási konfiguráció párbeszédablak a J2EE perspektívából érhető el a Futtatás > Futtatás... elem kiválasztásával a termék eszköztárából. Ha az ügyfél több szálat használ, vagy ha olyan keretrendszert, például Swing-et használ, amely több szálat is használhat, akkor el kell végeznie az alábbi lépéseket:
- Az Alkalmazásügyfél indítási konfiguráció párbeszédablakban válassza ki az Argumentumok lapot. A VM argumentumok szövegmezőben adja meg a következő paramétert:
-Dosgi.noShutdown=true- Győződjön meg róla, hogy az ügyfélalkalmazás meghívja a System.exit() metódust.
Ha ezek nincsenek megadva, akkor problémák jelentkezhetnek az osztályok betöltésekor vagy az olyan Java™ virtuális gépeknél (JVM), amelyek az alkalmazás futásának befejezésekor nem lépnek ki.
Tegyük fel, hogy rendelkezik egy Alkalmazásügyfél projekttel az alábbi konfigurációban:
- A Java projektrész az 1.4 változatra van állítva
- A projekt cél kiszolgáló futási környezetében engedélyezve van a menet közbeni metóduscsere beállítás a kiszolgáló konfigurációjában
Azt tapasztalhatja, hogy a Folytatás gomb nem működik megfelelően a Hibakeresés nézetben. Például ha az alkalmazást hibakeresés módban futtatja a kiszolgálón és megpróbálja módosítani a forrást a futás közben, majd a Folytatás gombbal folytatja az alkalmazás hibakeresését. Azt tapasztalhatja, hogy a forráskód menet közbeni metóduscsere módosításai nem kerülnek alkalmazásra.
A futás közben módosítások életbe lépéséhez próbáljon meg kétszer a Folytatás gombra kattintani.
Megjegyzés: Ez a probléma nem jelentkezik ha a Java projektrészt 5.0 változatra állítja.
Az Eltávolítás gomb a Megosztott WebSphere kiszolgálók kezelése párbeszédablakban nem működik megfelelően.
Tanács: A Megosztott WebSphere kiszolgálók kezelése párbeszédablak megnyitásához végezze el az alábbi lépéseket:
- Válassza ki az eszköztár Ablak > Beállítások elemét. Megjelenik a Beállítások párbeszédablak.
- A baloldali ablakrészben válassza ki a Kiszolgáló > WebSphere > WebSphere v51 elemet.
- A jobboldali ablakrészben a Megosztott WebSphere kiszolgálók mező mellett kattintson a Kezelés gombra. Megjelenik a Megosztott WebSphere kiszolgálók kezelése párbeszédablak.
Ha az Eltávolítás gombot használja, akkor úgy látszik, hogy a kiszolgáló eltávolításra kerül. Ha viszont kilép a párbeszédablakból, ismét megnyitja a párbeszédablakot, majd frissíti a távoli kiszolgáló információit, akkor a korábban eltávolított kiszolgáló megjelenik a párbeszédablakban.
A probléma megkerülése érdekében távolítsa el manuálisan a megosztott kiszolgáló bejegyzést az alábbi lépések végrehajtásával:
- Nyissa meg az id.txt fájlt a következő könyvtárból:
<könyvtár>/plugins/com.ibm.etools.websphere.tools*/properties
ahol a <könyvtár> az Ügynökvezérlő telepítési könyvtára.- Törölje ki a törlendő megosztott kiszolgálóra hivatkozó bejegyzést.
- Távolítsa el az adott megosztott kiszolgálóhoz a kiszolgáló létrehozásakor megadott WebSphere telepítési könyvtárat valamint annak összes alkönyvtárát. Példák a WebSphere telepítési könyvtárából eltávolítandó könyvtárakra: config, installedApps, temp, valamint a könyvtárban található egyéb könyvtárak és fájlok.
- A Megosztott WebSphere kiszolgálók kezelése párbeszédablakban adjon meg egy hosztnevet, majd a Frissítés gombra kattintva győződjön meg róla, hogy a megosztott kiszolgáló sikeresen eltávolításra került.
Ha további kiszolgálók, például IBM HTTP kiszolgáló van telepítve ugyanabba a WebSphere Application Server 6.x profilba, akkor az Új kiszolgáló varázsló WebSphere kiszolgáló beállításai oldala nem biztos hogy megtalálja a helyes távoli metódushívás (RMI) vagy SOAP portszámokat. Ezenkívül elképzelhető hogy a rendszer nem keresi vissza az adminisztrációs konzol portszámát.
Ha az Új kiszolgáló varázsló nem találja az egyik kiszolgálóhoz meghatározott tényleges portszámot, akkor alapértelmezésben előre kitölti a port mezőket az alapértelmezett portszámokkal: RMI-nél 2809, SOAP-nál 8880.
Ha helytelen portszámok kerülnek megadásra, akkor az alábbi problémákba ütközhet:
- Nem lehet csatlakozni a kiszolgálóhoz, például nem lehet elindítani vagy leállítani.
- Nem lehet megnyitni az adminisztrációs konzolt az új kiszolgálóról, és egy hibaüzenet jelezheti, hogy az adminisztrációs konzol portja nincs meghatározva.
- Nem lehet alkalmazásokat futtatni a kiszolgálón, így a Futtatás kiszolgálókon parancs például nem működik.
Kerülő megoldás:
- A kiszolgáló konfigurációs fájljai segítségével határozza meg a beállított profil port értékeit. A port értékeket a rendszer a serverindex.xml fájlban tárolja a következő könyvtárban:
<könyvtár>\profiles\<profilnév>\config\cells\<cellanév>\nodes\<csomópontnév>, ahol a <könyvtár> a WebSphere alkalmazáskiszolgáló telepítési könyvtára.
A serverindex.xml fájl segítségével töltse ki az alábbi táblázatot és határozza meg a kiszolgálóhoz megadott tényleges portszámokat:
Portnév Port leírása Alapértelmezett portszám Hozzárendelt portszám SOAP_CONNECTOR_ADDRESS SOAP 8880 BOOTSTRAP_ADDRESS RMI 2809 WC_adminhost Adminisztrációs konzol 9060 WC_defaulthost HTTP szállítás 9080 - A kiszolgálóhoz való csatlakozáshoz adja meg a helyes RMI és SOAP portszámokat a kiszolgáló létrehozásakor.
- Az adminisztrációs konzol elindításához használjon külső webböngészőt, és írja be a helyes adminisztrációs konzol port URL címét a cím mezőbe:
http://<számítógépnév>:<WC_adminhost>/IBM/console
Például: http://localhost:9060/IBM/console- Ha alkalmazásokat szeretne futtatni a kiszolgálón, akkor adja ki a Futtatás kiszolgálón parancsot. Amikor a webböngésző megnyílik, akkor javítsa ki a kiszolgálóhoz megadott helyes HTTP szállítási portszámot az URL címben.
http://<számítógépnév>:<WC_defaulthost>/<kontextusgyökér>/<alkalmazás_kezdőoldala>
Például: http://localhost:9080/MyApplication/index.jsp
Megjegyzés: A Kiszolgálók nézetben automatikusan meghatározott kiszolgálók nem biztos hogy a tényleges kiszolgáló helyes portszámaira hivatkoznak. Ebben az esetben alkalmazza a fenti kerülő megoldást.
A Profilkezelő egy olyan WebSphere alkalmazáskiszolgáló eszköz, amely profilt hoz létre minden egyes futási környezethez. A WebSphere alkalmazáskiszolgáló Profilkezelő eszközét a munkaterületről indíthatja el. A Profilkezelő eszköz nem működik 64 bites processzoron, így ezeken a rendszereken használja a WebSphere alkalmazáskiszolgáló manageprofiles parancssori eszközét.
Ha Windows operációs rendszereken távoli metódushívást (RMI) használ a WebSphere Application Server v6.x kiszolgálóra való csatlakozáshoz, akkor a hálózati kapcsolat elvesztése után hosszú várakozási időt tapasztalhat a kapcsolat létrehozásakor. Ez még akkor is előfordulhat, ha a kiszolgáló távoli, és a hálózati kapcsolat csak ideiglenesen veszett el, ami a vezetéknélküli hálózatokban általános jelenség.
Ha tudja hogy a kiszolgáló el van indítva, de a Kiszolgálók nézet a Leállítva vagy az Indítás állapotot mutatja, akkor a kiszolgáló kapcsolat RMI-ről SOAP-ra váltásával próbáljon meg kapcsolatot létrehozni a kiszolgálóval. A kiszolgáló állapotának Elindítva állapotra kell változnia.A vezetéknélküli környezetekben számos lehetőség van kapcsolat létrehozására egy kiszolgálóval:
- A legkönnyebb és legbiztonságosabb módszer a kapcsolat átváltása a SOAP port használatára. A hálózati kapcsolat elvesztése után a SOAP kapcsolatok gyorsabban helyreállnak mint az RMI kapcsolatok.
- Ha RMI kapcsolatot kell használnia, akkor megpróbálhatja módosítani a Windows operációs rendszer Tartománynév kiszolgáló (DNS) gyorsítótárában lévő alapértelmezett beállításokat. Részletes információkat a következő Microsoft támogatási cikkben talál:
http://support.microsoft.com/kb/318803
A Windows operációs rendszer egy beépített DNS gyorsítótárral rendelkezik, amely karbantartja a feloldott hosztneveket. Így gyorsabb válaszidőket lehet elérni a DNS keresések kiadásakor. Ez viszont hátrányos, ha a DNS keresés meghiúsul. A Windows operációs rendszer alapértelmezésben 300 másodpercre gyorsítótárba helyezi a meghiúsult értéket. Akkor sem próbálja meg ténylegesen elvégezni a keresést a gyorsítótár időkorlátjának lejáratáig, ha a DNS kiszolgáló rövid időn belül már fel tudná oldani a keresést. Ennek eredményként a alapértelmezett beállításokkal végzett sikertelen DNS keresések ténylegesen 5 percig nem próbálkoznak újra a kereséssel. A gyorsítótár időkorlátjának 0 másodpercre állítása kényszeríti a Windows operációs rendszert, hogy soha ne tárolja gyorsítótárban a DNS keresési lekérdezéseket, és hogy azonnal csatlakozzon, amint a DNS elérhetővé válik.
Példa a sikertelen keresések DNS gyorsítótárban való eltárolásának letiltására Windows operációs rendszerken:
A következő rendszerleíró adatbázis kulcsban: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Adja hozzá a következő rendszerleíró adatbázis értéket:
- Windows XP/2003:
"MaxNegativeCacheTtl"=dword:00000000- Windows 2000:
"NegativeCacheTime"=dword:00000000
Az alkalmazások ismételt közzététele, újraindítása vagy eltávolítása és újratelepítése nem elegendő az Alkalmazás telepítésleíró szerkesztő Telepítés oldalán megadott számos erőforrás módosítás alkalmazásához a kiszolgálón. A szerkesztő Telepítés oldalán megadott adatforrás adatbázisnevének módosítása egy olyan változás, amelyet a kiszolgáló nem vesz át, de lehetnek más ilyen módosítások is.
Kerülő megoldásként az alábbi lépések végrehajtásával alkalmazza a módosításokat a kiszolgálón:
- Állítsa le a kiszolgálót.
- A Kiszolgálók nézetben kattintson a jobb egérgombbal a kiszolgálóra, majd válassza az előugró menü Leállítás menüpontját.
- A Kiszolgálók nézetben várja meg, amíg a kiszolgáló állapota Leállítva állapotra nem változik, majd folytassa a következő lépéssel.
- Indítsa el a munkaterületet.
MEGJEGYZÉS: A kiszolgáló nem áll le, akkor az operációs rendszer funkcióval kell leállítania azt a java folyamatot, amelyen a kiszolgáló fut. Vagy indítsa újra a munkaterületet, és próbálja meg ismét elindítani a kiszolgálót.- Indítsa el a kiszolgálót.
- A Kiszolgálók nézetben kattintson a jobb egérgombbal a kiszolgálóra, majd válassza az előugró menü Elindítás menüpontját.
- A Kiszolgálók nézetben várja meg a közzététel befejeződését és a kiszolgáló valamint az alkalmazás állapotának Elindítva állapotra változását, majd folytassa a következő lépéssel.
- Futtassa az alkalmazást a kiszolgálón. Használja például a Futtatás kiszolgálón parancsot. A kiszolgálónak mostmár át kell vennie az Alkalmazás telepítésleíró szerkesztő módosításait.
Ha egy webprojekt webes könyvtáraihoz egy segédprogram JAR fájlt ad hozzá és a kódban a JAR fájlon belüli osztályokra hivatkozik, akkor az alkalmazás kiszolgálón való futtatásakor egy java.lang.NoClassDefFoundError hiba jelentkezhet.
Kerülő megoldásként először adja hozzá a segédprogram JAR fájlt az EAR modulhoz, majd adja hozzá a JAR fájlt a web projekt J2EE modul függőségeihez. Ehhez végezze el az alábbi lépéseket:
- Adjon hozzá egy segédprogram JAR fájlt az EAR modulhoz. Részletes információkat a Projekt segédprogram JAR fájlok hozzáadása témakörben talál.
- Kattintson a jobb egérgombbal a web projekten, majd válassza az előugró menü Tulajdonságok menüpontját. Megjelenik a Tulajdonságok párbeszédablak.
- Válassza ki a J2EE modul függőségek elemet.
- A J2EE modulok lapon a JAR/modul oszlopban válassza ki a saját JAR fájlja melletti jelölőnégyzetet.
Ha egy WebSphere Application Server 6.1 biztonságos SOAP kapcsolaton fut, akkor egy másik WebSphere Application Server 6.0 biztonságos SOAP kapcsolata meg fog hiúsulni. A probléma fordított esetben is jelentkezik, tehát ha egy WebSphere Application Server 6.0 biztonságos SOAP kapcsolaton fut, akkor egy másik WebSphere Application Server 6.1 biztonságos SOAP kapcsolata meg fog hiúsulni. A probléma viszont nem jelentkezik, ha a kiszolgáló meg van határozva a Kiszolgálók nézetben, és az állapota üres.
A probléma megkerülése érdekében a biztonságos SOAP kapcsolat helyett használjon biztonságos távoli metódushívás (RMI) kapcsolatot a kiszolgálóhoz, vagy használjon nem biztonságos SOAP kapcsolatot.
Ha a távoli kiszolgáló le van állítva, akkor az Új kiszolgáló varázsló befejezéséhez a Befejezés gombra kattintás után hosszú időre van szükség. A kerülő megoldás a távoli kiszolgáló elindítása még mielőtt a Befejezés gombra kattintana az Új kiszolgáló varázslóban.
Ha egy EAR projekt EarContent mappájába egy .war kiterjesztésű fájlt helyez és a fájl nincs meghatározva webmodulként az application.xml fájlban, akkor a vállalati alkalmazás a kiszolgálóra való közzététel közben hibába ütközik, és a következő példa hibaüzenet jelenik meg:
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0034E Az "abc.war" beágyazott archívumot nem lehet megnyitni a "D:\myworkspace\PublishEAR\EarContent" helyenA hiba oka, hogy a munkaterület nem tudja a fájlt helyesen webmodulként kezelni. Az alábbi kerülő megoldások közül választhat:
- Ha a fájl egy webmodul, akkor adja hozzá a fájlt modulként a vállalati alkalmazáshoz. Részletes információkat a termék súgójának Modulok hozzáadása a vállalati alkalmazásokhoz témakörében talál.
- Ha a fájl nem egy webmodul, akkor a közzétételi probléma kikerülésének ajánlott módja a .war fájlkiterjesztés módosítása például.jar kiterjesztésre.
Ha egy távoli WebSphere Application Server 5.1 vagy egy távoli WebSphere Application Server 5.1 Express kiadásnál módosítja a telepítési könyvtárat vagy a közzétételi könyvtárat a kiszolgáló szerkesztőben majd közzéteszi az alkalmazást, akkor az alkalmazás továbbra is a korábbi célra kerül közzétételre. Ezért a közzétételi és telepítési könyvtárakban végzett módosítások nem kerülnek alkalmazásra. Ez a probléma akkor jelentkezik, ha helyi másolatot vagy FTP metódusokat használ.
A probléma megkerülése érdekében indítsa újra a munkaterületet. Így a közzétételi könyvtár és a telepítési könyvtár konfigurációs módosításai életbe lépnek.
A projektek tárolásának még rugalmasabbá tétele érdekében az alkalmazások közzétételének technikája módosításra került. A rendszer az alkalmazásokat a kiszolgálóra való közzététel előtt átmásolja. Ha az alkalmazás nagyméretű, például nagyobb mint 100 megabyte, akkor a közzétételhez használt másolási művelet több időt vehet igénybe, mint amit a korábbi változaton tapasztalt.
Jelenleg nincs kerülő megoldás. Az IBM dolgozik egy frissítésen, amely a legtöbb esetben kiküszöböli ennek az új másolási műveletnek a szükségességét.
Ha egy biztonságos WebSphere Application Server 6.1 kiszolgálót indít el és a kiszolgáló szerkesztőben távoli metódushívásra (RMI) vagy SOAP-ra módosítja a kiszolgálókapcsolat típusát, akkor a módosítások kiszolgáló szerkesztőben való mentése után a következő hibaüzenet jelenhet meg:
A közzététel nem került végrehajtásra, mert a kiszolgáló nincs elindítva. A kiszolgáló elindításához hajtsa végre a közzététel műveletet.
A hibát nyugodtan figyelmen kívül hagyhatja. Vagy ha a kiszolgáló állapota a Kiszolgálók nézetben Elindítva állapotra változik, akkor befejezheti a közzététel parancsot (a Kiszolgálók nézetben kattintson a jobb egérgombbal a kiszolgálóra, majd válassza az előugró menü Közzététel menüpontját).
Ha a Tábla és adatforrás létrehozó varázsló használatával próbál meg adatforrást előállítani, akkor a Tábla és adatforrás létrehozó eredménye párbeszédablak Részletek ablakrészében egy TargetInvocationException hiba jelenhet meg.
A TargetInvocationException hiba akkor fordulhat elő, ha azonos JNDI névvel rendelkező adatforrásokat tartalmazó projekt adatcserét importál.
A TargetInvocationException hiba elkerülése érdekében ellenőrizze, hogy van-e más adatforrás meghatározva a munkaterületen azonos JNDI névvel. Ha van, akkor távolítsa el az Alkalmazás telepítés leíró szerkesztő Telepítés oldaláról, majd hozza létre ismét az adatforrást egy másik JNDI névvel. A JNDI névnek egyedinek kell lennie, mivel ez egy elnevezési és keresési szolgáltatás, amelyet a rendszer a vállalati komponensek adatforráshoz kötéséhez használ.
Elképzelhető hogy a kiszolgáló nem áll le teljesen, ha a kiszolgálót a Kiszolgálók nézetből állítja le. A Kiszolgálók nézetben a Leállítva állapot jelenik meg, lehetséges hogy a kiszolgáló folyamat nem válaszol állapotban van. Ez általában akkor fordul elő, ha az alkalmazásai vagy a munkaterület fenntartja a kiszolgálón található osztályokra való hivatkozásokat. Az alábbiak példahelyzetek:
- A végtelen ciklusban lévő alkalmazások vagy a kiszolgálón található osztályokra való hivatkozásokat fenntartó alkalmazások
- Alkalmazások, amelyek a saját kapcsolatuk kitakarítása nélkül használnak Cloudscape vagy Derby adatbázis kapcsolatot
- Cloudscape vagy Derby adatbáziskapcsolat megnyitása az adateszközök Új kapcsolat varázslójának Kapcsolat tesztelése gombjával az adatbázisról való lecsatlakozás nélkül
Megszorítás: A Cloudscape és Derby adatbázisokhoz a Cloudscape illetve Derby konfigurációs megszorítások miatt több kapcsolat nem támogatott. Ha fenntartja az adatbázis kapcsolatot az Adatbázis böngészőből és a kiszolgáló egy másik Cloudscape vagy Derby kapcsolatot próbál meg létrehozni egy adatforráson keresztül, akkor a második kapcsolat meghiúsul. A kiszolgáló csak azután tud kapcsolatot létrehozni a Cloudscape vagy Derby adatbázissal, miután lezárta a kapcsolatot az Adatbázis böngészőből.
A probléma megkerülése érdekében az operációs rendszer funkcióival kell leállítania azt a java folyamatot, amelyen a kiszolgáló fut. Vagy kikényszerítheti a hivatkozás felszabadítását a munkaterület újraindításával is. Az harmadik pontban bemutatott utolsó példahelyzetben az Adatbázis böngésző nézettel csatlakozhat a Cloudscape vagy Derby adatbázishoz, majd megszakíthatja a kapcsolatot.
Ha az erőforrások (például egy vállalati komponens) kiszolgálóra való közzétételekor Univerzális teszt ügyfelet (UTC) használ egy Vállalati JavaBean komponens teszteléséhez, akkor előfordulhat, hogy a JAR fájl zárolásra kerül, és nem lehet frissíteni. Ennek eredményeként az eszközben végzett módosítások nem kerülnek alkalmazásra a Vállalati JavaBean komponens tesztelése közben. Ha az UTC már betöltötte a Vállalati JavaBean komponens JAR fájlját, akkor a JAR fájl addig zárolt marad, amíg az alkalmazást el nem távolítja és ismét hozzá nem adja, vagy amíg a kiszolgálót újra nem indítja.
A probléma megkerülése érdekében az UTC-t használja olyan fejlesztői környezetben, ahol az alkalmazás erőforrásai a munkaterületen kívül futnak, és nem a kiszolgálón. Ezt az Új kiszolgáló varázslóval állíthatja be, vagy később is megadhatja a kiszolgáló szerkesztőben, ha a Kiszolgáló futtatása erőforrásokkal a munkaterületen beállítást kiválasztja a Közzététel beállításaiban. Ez lehetővé teszi a Vállalati JavaBean komponensben lévő egyes fájlok frissítését a teljes Vállalati JavaBean komponens JAR fájl lecserélése nélkül.
Ha az alkalmazás tesztelését elvégezte, akkor közzéteheti a Kiszolgáló futtatása erőforrásokkal a kiszolgálón közzétételi beállítással.