© Copyright International Business Machines Corporation 2006. Wszelkie prawa zastrzeżone. Ograniczone prawa na rzecz rządu Stanów Zjednoczonych - używanie produktów, tworzenie ich duplikatów oraz ujawnianie informacji o nich podlega zastrzeżeniom zawartym w umowie GSA ADP Schedule zawartej z firmą IBM® Corp.
Opcja Minimalizowanie plików aplikacji kopiowanych na serwer jest obsługiwana przez serwer WebSphere® Application Server, wersja 6.0.2.5 i nowsze. W edytorze serwera WebSphere Application Server, wersja 6.0, znajduje się pole wyboru dla tej opcji. Jednak jego zaznaczenie dla serwera w wersji wcześniejszej niż wersja 6.0.2.5 zostanie zignorowane.
Jeśli moduł Enterprise JavaBean (EJB) jest współużytkowany przez wiele projektów EAR działających na serwerze WebSphere Application Server i jeden z projektów EAR zostanie usunięty z serwera, pozostałe projekty EAR muszą zostać zrestartowane zanim będą mogły uzyskać dostęp do zasobów, takich jak komponenty bean w projekcie EJB.
Jeśli użytkownik nie wykona tej czynności, mogą zostać wyświetlone komunikaty o błędach podobne do poniższych. Te błędy występują, ponieważ nazwa interfejsu JNDI (Java Naming and Directory Interface) w projekcie EJB zostanie usunięta z serwera podczas usuwania projektu EAR.
Poniżej przedstawiono przykładowy komunikat o błędzie:
00000028 SystemOut O javax.naming.NameNotFoundException: Context: myCell/nodes/myNode/servers/server1, name: ejb/ejbs/Session20Home: Nie znaleziono pierwszego komponentu w nazwie Session20Home. [Wyjątek główny to 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)
Z powodu różnych zachowań i interakcji między środowiskami wykonawczymi Eclipse i WebSphere, podczas uruchamiania wielowątkowych klientów aplikacji WebSphere za pomocą okna dialogowego Konfiguracje uruchamiania klientów aplikacji należy wykonać dodatkowe czynności. Okno dialogowe Konfiguracje uruchamiania klientów aplikacji jest dostępne w perspektywie J2EE po wybraniu opcji: Uruchom > Uruchom... na pasku narzędzi produktu. Jeśli klient korzysta z wielu wątków lub ze środowisk, które mogą wykorzystywać dodatkowe wątki, takie jak Swing, należy wykonać następujące czynności dodatkowe:
- W oknie dialogowym Konfiguracje uruchamiania klientów aplikacji wybierz zakładkę Argumenty. W polu tekstowym Argumenty maszyny VM podaj następujący parametr:
-Dosgi.noShutdown=true- Upewnij się, że aplikacja kliencka wywołuje metodę System.exit()
Jeśli powyższe czynności nie zostaną wykonane, mogą pojawić się problemy związane z ładowaniem klas lub z wirtualnymi maszynami języka Java™ (JVM), które nie powodują wyjścia po wykonaniu aplikacji.
Załóżmy, że mamy projekt, na przykład projekt aplikacji klienckiej, o następującej konfiguracji:
- aspekt projektu dla języka Java jest ustawiony na wersję 1.4,
- w środowisku wykonawczym serwera docelowego dla tego projektu jest włączona opcja zstępowania metody na bieżąco w konfiguracji serwera.
Może się okazać, że przycisk Wznów w widoku Debugowanie nie działa poprawnie. Na przykład po uruchomieniu aplikacji na serwerze w trybie debugowania i podjęciu próby zmiany źródła w środowisku wykonawczym, a następnie użyciu przycisku Wznów w celu kontynuowania debugowania aplikacji. Może się okazać, że zmiany zastępowania metody na bieżąco w kodzie źródłowym nie zostaną zastosowane.
Spróbuj dwukrotnie kliknąć przycisk Wznów w celu aktywowania zmian w środowisku wykonawczym.
Uwaga: Ten problem nie występuje, jeśli aspekt projektu dla języka Java jest ustawiony na wersję 5.0.
Przycisk Usuń w oknie dialogowym Zarządzaj współużytkowanymi serwerami WebSphere nie działa poprawnie.
Wskazówka: Aby otworzyć okno dialogowe Zarządzaj współużytkowanymi serwerami WebSphere:
- Na pasku narzędzi wybierz opcje: Okno > Preferencje. Zostanie otwarte okno dialogowe Preferencje.
- Na panelu po lewej stronie wybierz kolejno opcje: Serwer > WebSphere > WebSphere 51.
- Na panelu po prawej stronie obok pola Współużytkowane serwery WebSphere kliknij przycisk Zarządzaj. Zostanie otwarte okno dialogowe Zarządzaj współużytkowanymi serwerami WebSphere.
Użycie przycisku Usuń spowoduje usunięcie serwera. Jednak po wyjściu z okna dialogowego, a następnie po ponownym jego otwarciu i odświeżeniu informacji o serwerach zdalnych, poprzednio usunięty serwer pojawia się z powrotem.
Aby obejść ten problem, można ręcznie usunąć wpis serwera współużytkowanego, wykonując następujące czynności:
- Otwórz plik id.txt, który znajduje się w następującym katalogu:
<katalog>/plugins/com.ibm.etools.websphere.tools*/properties
gdzie <katalog> to katalog instalacyjny produktu Agent Controller.- Usuń wpis z odniesieniem do serwera współużytkowanego, który chcesz usunąć.
- Usuń katalog instalacyjny WebSphere, który został określony dla tego danego serwera współużytkowanego podczas jego tworzenia, a także wszystkie jego podkatalogi. Przykłady podkatalogów do usunięcia z katalogu instalacyjnego serwera WebSphere to: config, installedApps, temp oraz wszystkie pozostałe katalogi i pliki, które znajdują się w tym katalogu.
- W oknie Zarządzaj współużytkowanymi serwerami WebSphere podaj nazwę hosta i kliknij przycisk Odśwież, aby sprawdzić, czy serwer współużytkowany został usunięty pomyślnie.
W przypadku dodatkowych serwerów, takich jak IBM HTTP Server, zainstalowanych w tym samym profilu serwera WebSphere Application Server, wersja 6.x, strona Ustawienia serwera WebSphere kreatora Nowy serwer może nie odszukać poprawnych numerów portów zdalnego wywołania metody (RMI) lub SOAP. Dodatkowo może nie zostać pobrany numer portu dla konsoli administracyjnej.
Gdy kreator Nowy serwer nie może odszukać bieżących numerów portów zdefiniowanych dla serwera, domyślnie wypełnia pola portów domyślnymi numerami: 2809 dla RMI i 8880 dla SOAP.
W takim przypadku, gdy zostaną zdefiniowane niepoprawne numery portów, mogą pojawić się następujące problemy:
- Brak połączenia z nowym serwerem i brak możliwości jego uruchomienia lub zatrzymania.
- Brak możliwości otwarcia konsoli administracyjnej dla nowego serwera i pojawienie się błędu braku zdefiniowanego portu konsoli administracyjnej.
- Brak możliwości uruchomienia aplikacji na tym serwerze, ponieważ komenda Uruchom na serwerze nie działa.
Sposób obejścia:
- Określ wartości portów dla skonfigurowanego profilu, odczytując je z plików konfiguracyjnych serwera. Wartości portów są przechowywane w pliku serverindex.xml znajdującym się w następującym katalogu:
<katalog>\profiles\<nazwaProfilu>\config\cells\<nazwaKomórki>\nodes\<nazwaWęzła>, gdzie <katalog> to katalog instalacyjny serwera WebSphere Application Server.
Korzystając z pliku serverindex.xml wypełnij poniższą tabelę, aby określić bieżące numery portów zdefiniowane dla serwera:
Nazwa portu Opis portu Domyślny numer portu Przypisany numer portu SOAP_CONNECTOR_ADDRESS Interfejs SOAP 8880 BOOTSTRAP_ADDRESS RMI 2809 WC_adminhost Konsola administracyjna 9060 WC_defaulthost Transport HTTP 9080 - Aby połączyć się z serwerem, podczas tworzenia serwera określ poprawne numery portów RMI lub SOAP.
- Aby uruchomić konsolę administracyjną, użyj zewnętrznej przeglądarki WWW i w polu adresu wpisz adres URL do poprawnego portu konsoli administracyjnej:
http://<nazwa_komputera>:<WC_adminhost>/IBM/console
Na przykład: http://localhost:9060/IBM/console- Aby uruchomić aplikacje na serwerze, wywołaj komendę Uruchom na serwerze. Gdy otworzy się przeglądarka WWW, popraw adres URL, podając numer portu transportu HTTP zdefiniowany dla serwera.
http://<nazwa_komputera>:<WC_defaulthost>/<ContextRoot>/<strona_startowa_aplikacji>
Na przykład: http://localhost:9080/MojaAplikacja/index.jsp
Uwaga: Serwery automatycznie zdefiniowane w widoku Serwery mogą nie mieć odniesienia do poprawnych numerów portów bieżącego serwera. W takim przypadku także należy skorzystać z powyższego sposobu obejścia tego problemu.
Narzędzie do zarządzania profilami jest narzędziem serwera WebSphere Application Server, które tworzy profil dla każdego środowiska wykonawczego. Do uruchomienia narzędzia do zarządzania profilami serwera WebSphere Application Server można wykorzystać środowisko robocze. Jednak narzędzie do zarządzania profilami nie działa w systemach z procesorem 64-bitowym. Zamiast niego należy uruchomić z wiersza komend narzędzie manageprofiles udostępniane przez serwer WebSphere Application Server.
W systemach operacyjnych Windows, w przypadku korzystania z portu zdalnego wywoływania metody (RMI) w celu połączenia z serwerem WebSphere Application Server, wersja 6.x, po utracie połączenia sieciowego może wystąpić długie opóźnienie podczas ustanawiania połączenia z serwerem. Problem może wystąpić nawet jeśli serwer jest lokalny, a połączenie sieciowe zostało utracone tylko tymczasowo, co jest często spotykane w środowiskach sieci bezprzewodowej.
Jeśli serwer jest uruchomiony, ale jego status w widoku Serwery to Zatrzymano lub Uruchamianie, należy spróbować ustanowić połączenie z serwerem, przełączając połączenie serwera z RMI na SOAP. Status serwera powinien zmienić się na Uruchomiony.Do ustanowienia połączenia z serwerem w środowiskach sieci bezprzewodowej służy kilka opcji:
- Najprostszym i najbezpieczniejszym sposobem jest przełączenie połączenia na port SOAP. Po utracie połączenia sieciowego połączenia SOAP są przywracane szybciej niż połączenia RMI.
- Jeśli połączenie RMI jest wymagane, można spróbować zmodyfikować domyślne ustawienia dotyczące buforowania usługi DNS w systemie operacyjnym Windows. Szczegółowe informacje na ten temat zawiera artykuł w bazie wiedzy firmy Microsoft:
http://support.microsoft.com/kb/318803
System operacyjny Windows ma wbudowany bufor DNS, w którym są przechowywane rozstrzygnięte nazwy hostów. Zapewnia to szybsze odwracanie nazw podczas wyszukiwania DNS. Jednak w przypadku nieudanego wyszukiwania DNS występuje działanie niekorzystne. System operacyjny Windows buforuje niepoprawną wartość przez domyślny czas 300 sekund. Nawet jeśli serwer DNS krótko po tym może rozstrzygnąć wyszukiwanie, w rzeczywistości nie próbuje przeprowadzać wyszukiwania, dopóki nie upłynie czas buforowania. W wyniku tego nieudane wyszukiwanie DNS z wykorzystaniem ustawień domyślnych może trwać 5 minut, zanim podjęte zostanie prawdziwe ponowienie wyszukiwania. Ustawienie zegara buforu na 0 sekund wymusza na systemie Windows, aby nigdy nie buforował nieudanych zapytań wyszukiwania DNS i umożliwiał ponowne łączenie, gdy tylko serwer DNS będzie dostępny.
Poniżej przedstawiono sposób wyłączenia w systemie operacyjnym Windows buforowania nieudanych wyszukiwań:
W kluczu rejestru: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Należy dodać następującą wartość rejestru:
- W systemie Windows XP/2003:
"MaxNegativeCacheTtl"=dword:00000000- W systemie Windows 2000:
"NegativeCacheTime"=dword:00000000
Ponowne publikowanie aplikacji, restartowanie aplikacji lub deinstalowanie i ponowne instalowanie aplikacji nie jest wystarczające, aby zastosować niektóre zmiany zasobów zdefiniowane na stronie Wdrażanie edytora deskryptora wdrażania aplikacji na serwerze. Zmiana nazwy bazy danych źródła danych na stronie Wdrażanie edytora jest znaną zmianą, której serwer nie może wprowadzić. Oprócz tego może być kilka innych takich zmian.
Opisane poniżej czynności umożliwiają wprowadzenie zmian na serwerze. Jest to sposób obejścia tego problemu:
- Zatrzymaj serwer.
- W widoku Serwery kliknij prawym przyciskiem myszy dany serwer i wybierz opcję Zatrzymaj.
- Poczekaj, aż status serwera zmieni się na Zatrzymano i przejdź do następnego kroku.
- Uruchom środowisko robocze.
UWAGA: Jeśli uruchomienie serwera nie powiedzie się, należy skorzystać z funkcji systemu operacyjnego, aby zatrzymać proces java, w którym serwer jest uruchomiony. Alternatywnie można zrestartować środowisko robocze, a następnie uruchomić serwer ponownie.- Uruchom serwer.
- W widoku Serwery kliknij prawym przyciskiem myszy dany serwer i wybierz opcję Uruchom.
- Poczekaj w widoku Serwery, aż ponowne publikowanie zakończy się, a status serwera i aplikacji zmieni się na Uruchomiony, i przejdź do następnego kroku.
- Uruchom aplikację na serwerze, na przykład za pomocą komendy Uruchom na serwerze. Wynikiem tych działań powinno być wprowadzenie przez serwer zmian z edytora deskryptora wdrażania aplikacji.
Po dodaniu pliku JAR programu narzędziowego do bibliotek WWW dla projektu WWW i odwołaniu się do klas z pliku JAR w kodzie podczas próby uruchomienia aplikacji na serwerze może zostać wyświetlony błąd java.lang.NoClassDefFoundError.
Aby temu zapobiec, po dodaniu pliku JAR programu narzędziowego do modułu EAR należy dodać plik JAR do zależności modułów J2EE projektu WWW, wykonując następujące kroki:
- Dodaj plik JAR programu narzędziowego do modułu EAR. Szczegółowe informacje można znaleźć w temacie Dodawanie plików JAR programów narzędziowych projektu w pomocy do produktu.
- Kliknij prawym przyciskiem myszy projekt WWW i wybierz opcję Właściwości. Zostanie otwarte okno dialogowe Właściwości.
- Wybierz opcję Zależności modułów J2EE.
- Na karcie Moduły J2EE w kolumnie Plik JAR/moduł zaznacz pole wyboru obok pliku JAR danego programu narzędziowego.
Jeśli serwer WebSphere Application Server, wersja 6.1, działa z wykorzystaniem bezpiecznego połączenia SOAP, ustanowienie innego bezpiecznego połączenia SOAP z serwerem WebSphere Application Server, wersja 6.0, nie powiedzie się. Ten sam problem występuje także w odwrotnym przypadku, gdy serwer WebSphere Application Server, wersja 6.0, działa z wykorzystaniem bezpiecznego połączenia SOAP, to bezpieczne połączenie SOAP z serwerem WebSphere Application Server, wersja 6.1, również nie powiedzie się. Jednak problem nie występuje, jeśli serwer jest zdefiniowany w widoku Serwery, a jego status jest pusty.
Sposobem obejścia tego problemu jest użycie połączenia zdalnego wywołania metody (RMI) z serwerem - zamiast połączenia SOAP - lub użycie niezabezpieczonego połączenia SOAP.
Jeśli serwer zdalny jest zatrzymany, kreator nowego serwera może wymagać więcej czasu do ukończenia pracy po kliknięciu przycisku Zakończ. Sposobem obejścia jest uruchomienie serwera zdalnego przed kliknięciem przycisku Zakończ w kreatorze Nowy serwer.
Jeśli w folderze EarContent projektu EAR znajduje się plik .war, który nie został zdefiniowany jako moduł WWW w pliku application.xml, publikowanie aplikacji korporacyjnej na serwerze zakończy się następującym komunikatem o błędzie:
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0034E Nie można otworzyć archiwum "abc.war" zagnieżdżonego w "D:\myworkspace\PublishEAR\EarContent"Przyczyną tego błędu jest to, że środowisko robocze nie może poprawnie obsłużyć tego pliku jako modułu WWW. Można wybrać jeden z następujących sposobów obejścia problemu:
- Jeśli plik jest modułem WWW, dodaj go do aplikacji korporacyjnej jako moduł. Szczegółowe informacje zawiera temat pomocy produktu Dodawanie modułów do aplikacji korporacyjnej.
- Jeśli plik nie jest modułem WWW, sugerowanym sposobem obejścia problemu jest zmiana rozszerzenia pliku .war na przykład na rozszerzenie .jar
W przypadku zdalnego serwera WebSphere Application Server, wersja 5.1, lub WebSphere Application Server, wersja 5.1, Express Edition, jeśli w edytorze serwera zostanie zmieniony katalog wdrażania i publikowania, a następnie aplikacja zostanie ponownie opublikowana, jej miejscem publikacji będzie poprzedni katalog. Zmiana katalogów publikowania i wdrażania nie zostanie zastosowana. Ten problem występuje w przypadku korzystania z kopii lokalnej lub metod FTP.
Sposobem obejścia tego problemu jest zrestartowanie środowiska roboczego. Powinno to spowodować zastosowanie zmian konfiguracji katalogów publikowania i wdrażania.
Aby wprowadzić obsługę bardziej elastycznego podejścia do zapisywania projektów, technika publikowania aplikacji została zmieniona. Aplikacje są teraz kopiowane przed opublikowaniem na serwerze. Jeśli aplikacja jest duża, na przykład większa niż 100 MB, operacja kopiowania wykorzystywana dla komendy publikowania wymaga dodatkowego czasu w porównaniu z tym, który był wymagany w poprzedniej wersji.
Aktualnie nie ma żadnego sposobu obejścia. Firma IBM pracuje nad aktualizacją, która w większości przypadków wyeliminuje potrzebę przeprowadzania nowej operacji kopiowania.
Jeśli zabezpieczony serwer WebSphere Application Server, wersja 6.1, został uruchomiony i w edytorze serwera użytkownik zmieni typ połączenia serwera na zdalne wywołanie metody (RMI) albo na SOAP, może zostać wyświetlony następujący komunikat o błędzie niepowodzenia publikowania po zapisaniu zmian w edytorze serwera:
Publikowanie nie zostało wykonane, ponieważ serwer nie jest uruchomiony. Należy uruchomić serwer przed wykonaniem operacji publikowania.
Można bezpiecznie zignorować ten błąd. Opcjonalnie, po zmianie statusu serwera w widoku Serwery na Uruchomiony, można zakończyć komendę publikowania (w widoku Serwery należy kliknąć serwer prawym przyciskiem myszy i wybrać opcję Publikuj).
Podczas próby wygenerowania źródła danych za pomocą kreatora Kreator tabel i źródeł danych w sekcji Szczegóły okna dialogowego Wyniki tworzenia tabel i źródeł danych może wystąpić błąd TargetInvocationException.
Błąd TargetInvocationException może się pojawić podczas importowania wymiany projektów, która zawiera źródła danych zdefiniowane z tą samą nazwą JNDI (Java Naming and Directory Interface).
Aby obejść błąd TargetInvocationException, należy sprawdzić, czy w środowisku roboczym jest już zdefiniowane źródło danych o tej samej nazwie JNDI. Jeśli tak, należy je usunąć ze strony Wdrażanie edytora deskryptora wdrażania aplikacji, a następnie utworzyć ponownie źródło danych, używając innej nazwy JNDI. Nazwa JNDI musi być unikalna, gdyż jest to usługa nazewnictwa i wyszukiwania wykorzystywana do wiązania komponentu EJB ze źródłem danych.
Jeśli serwer zostanie zatrzymany w widoku Serwery, może nie zatrzymać się całkowicie. W widoku Serwery zostanie wyświetlony status Zatrzymano, ale proces serwera może znajdować się w stanie braku odpowiedzi. Zazwyczaj ten problem występuje, gdy artefakt, taki jak aplikacja użytkownika lub środowisko robocze, utrzymuje na serwerze odniesienia do klas. Przykładowe scenariusze:
- Aplikacje, które znajdują się w nieskończonych pętlach, lub aplikacje utrzymujące odniesienia do klas na serwerze.
- Aplikacje nawiązujące połączenie z bazą danych Cloudscape lub Derby bez czyszczenia połączenia.
- Użycie przycisku Testuj połączenie w kreatorze Nowe połączenie narzędzi danych w celu otwarcia połączenia z bazą danych Cloudscape lub Derby bez uprzedniego rozłączania z bazą.
Ograniczenie: Wiele połączeń z pojedynczą bazą danych Cloudscape lub Derby nie jest obsługiwanych z powodu ograniczeń konfiguracji bazy danych Cloudscape lub Derby. Jeśli połączenie z bazą danych jest utrzymywane z eksploratora bazy danych, a serwer usiłuje ustanowić inne połączenie z bazą danych Cloudscape lub Derby za pośrednictwem źródła danych, drugie połączenie nie zostanie nawiązane. Przed ustanowieniem przez serwer połączenia z bazą danych Cloudscape lub Derby należy zamknąć połączenie z eksploratora bazy danych.
Aby obejść ten problem, należy użyć funkcji systemu operacyjnego i zatrzymać proces java, w którym serwer jest uruchomiony. Alternatywnie można zrestartować środowisko robocze, aby wymusić zwolnienie odniesienia. W ostatnim przykładzie możliwego scenariusza, opisanego w trzecim punkcie, można skorzystać z widoku eksploratora bazy danych, aby połączyć, a następnie rozłączyć się z bazą danych Cloudscape lub Derby.
Podczas publikowania zasobów na serwerze, na przykład komponentu EJB, oraz korzystania z uniwersalnego klienta testowego (UTC) do testowania komponentu EJB, może się zdarzyć, że plik JAR zostanie zablokowany, co uniemożliwi jego aktualizację. Powoduje to, że zmiany wprowadzone w narzędziu nie zostaną wprowadzone podczas testowania komponentu EJB. Gdy klient UTC załaduje plik JAR komponentu EJB, plik JAR pozostanie zablokowany dopóki aplikacja nie zostanie usunięta i dodana ponownie lub serwer nie zostanie zrestartowany.
Sposobem obejścia tego problemu jest użycie klienta UTC w środowisku programistycznym, w którym zasoby aplikacji są uruchomione poza obszarem roboczym i nie działają na serwerze. Taką konfigurację można utworzyć za pomocą kreatora Nowy serwer lub zmienić później za pomocą edytora serwera, wybierając opcję Uruchamianie serwera z zasobami w obszarze roboczym w opcjach Publikowanie. Umożliwia to aktualizowanie pojedynczych plików w ramach projektu EJB, bez konieczności pełnego zastępowania całego pliku JAR komponentu EJB.
Po pełnym przetestowaniu aplikacji można ją opublikować na serwerze za pomocą opcji publikowania Uruchamianie serwera z zasobami na serwerze.