[ Pobierz całość w formacie PDF ]
.Kiedy serwer wysyła zlecenie do apletu najpierw sprawdza, czy plik klasy apletu zmienił się nadysku.Jeżeli okaże się, że tak wtedy serwer nie będzie już używał programu ładującego starejwersji pliku tylko utworzy nowa kopię własnego programu ładującego klasy celemzaładowania nowej wersji.Niektóre serwery poprawiają wydajność poprzez sprawdzanieznaczników modyfikacji czasu tylko co jakiś czas lub na wyrazne żądanie administratora.W wersjach Interfejsów API sprzed wersji 2.2, chwyt z programem ładującym klasy skutkowałtym, że inne aplety ładowane były przez odmienne programy ładujące co skutkowało czasemzgłoszeniem ClassCastException jako wyjątku, kiedy aplety wymieniały informacje(ponieważ klasa załadowana przez jeden program ładujący nie jest tym samym, co klasa ładowanaprzez inny, nawet jeżeli dane dotyczące klasy są identyczne).Na początku Interfejsu API 2.2 jest gwarancja, że problemy z ClassCastException nie pojawisię dla apletów w tym samym kontekście.Tak więc obecnie większość wdrożeń ładuje każdy kontekst aplikacji WWW w jednym programie ładującym klasy, oraz używa nowego programuładującego do załadowania całego kontekstu, jeżeli jakikolwiek aplet w kontekście ulegniezmianie.Skoro więc wszystkim apletom oraz klasom wspomagającym w kontekście zawsze odpowiada tensam program ładujący, nie należy się więc obawiać żadnych nieoczekiwanychClassCastException podczas uruchamiania.Powtórne ładowanie całego kontekstu powodujemały spadek wydajności, który jednakże występuje tylko podczas tworzenia.Powtórne ładowanie (odnawianie) klasy nie jest przeprowadzane tylko wtedy, kiedy zmianie ulegaklasa wspomagająca.Celem większej efektywności określenia, czy jest konieczne odnawianiekontekstu, serwery sprawdzają tylko znaczniki czasu apletów klasy.Klasy wspomagające w WEB-INF/classes mogą być także powtórnie załadowane, kiedy kontekst jest odnowiony, lecz jeżeliklasa wspomagająca jest jedyną klasą do zmiany, serwer tego prawdopodobnie nie zauważy.Odnowienie apletu nie jest także wykonywane dla wszystkich klas (apletu lub innych)znajdujących się w ścieżce klasy serwerów.Klasy takie ładowane są przez rdzenny (pierwotny)program ładujący, a nie własny, konieczny do powtórnego załadowania.Klasy te są równieżładowane jednorazowo i przechowywane w pamięci nawet wtedy, gdy ich pliki ulegają zmianie.Jeżeli chodzi o klasy globalne (takie jak klasy użyteczności com.oreilly.servlet) to najlepiejjest umieścić je gdzieś na ścieżce klasy, gdzie unikną odnowienia.Przyśpiesza to procespowtórnego ładowania oraz pozwala apletom w innych kontekstach wspólnie używać tychobiektów bez ClassCastException.Metody Init i Destroy Tak jak zwykłe aplety, aplety wykonywane na serwerach mogą określać metody init() idestroy().Serwer wywołuje metodę init() po skonstruowaniu kopii apletu, jednak zanimjeszcze aplet obsłuży jakiekolwiek zlecenie.Serwer wywołuje metodę destroy() po wyłączeniuapletu i zakończeniu wszystkich zleceń lub po przekroczeniu ich limitu czasowego*.W zależności od rodzaju serwera oraz konfiguracji aplikacji WWW, metoda init() może zostaćwywołana w poniższych momentach:" podczas uruchamiania apletu" podczas pierwszego łączenia się z apletem, przed wywołaniem metody service()" na żądania administratora serweraW każdym przypadku metoda init() zostanie wywołana i zakończona ani zanim jeszcze apletobsłuży swoje pierwsze zlecenie.*Specyfikacji projektów mającego ukazać się na rynku apletu API 2.3 (Servlet API 2.3), zakładają, żedodane zostaną metody cyklu życia (czasu istnienia), które umożliwią apletom oczekiwanie na sygnały, kiedykontekst lub sesja są tworzone lub zakańczane oraz podczas wiązania i rozwiązywania atrybutu z kontekstemlub sesją. Metoda init() jest zwykle wykorzystywana do inicjalizacji apletu ładowania obiektówużywanych przez aplet w procesie obsługi zleceń.W czasie wykorzystywania metody init()aplet może chcieć odczytać swoje parametry inicjalizacji (init).Parametry te są dostarczanesamemu apletowi i nie są w jakikolwiek sposób związane z jednym zleceniem.Mogą one określaćtakie wartości początkowe jak: odkąd licznik powinien zacząć liczyć lub wartości domyślne takiejak np.szablon, który powinien zostać użyty w przypadku nie określenia tego w zleceniu.*Specyfikacji projektów mającego ukazać się na rynku interfejsu API 2.3 (Servlet API 2.3),zakładają, że dodane zostaną metody cyklu życia (czasu istnienia), które umożliwią apletomoczekiwanie na sygnały, kiedy kontekst lub sesja są tworzone lub zakańczane oraz podczaswiązania i rozwiązywania atrybutu z kontekstem lub sesją.Parametry początkowe dla apletu można znalezć w deskryptorze wdrożenia, niektóre serwery majągraficzne interfejsy mogące zmodyfikować ten plik (patrz przykład 3.3).Przykład 3.3.Ustalanie wartości parametrów w deskryptorze rozmieszczeniacounterInitCounterinitial1000The initial value for the counter
[ Pobierz całość w formacie PDF ]