Java Servlet 3.0 Specification czyli nadchodzą zmiany…

Filed Under Category Java by radoslaw.holewa

Ostatnio przeglądałem listę specyfikacji nad którymi trwają prace w ramach Java Community Process, w ten sposób natrafiłem na specyfikację oznaczoną JSR 315. Zapewne to oznaczenie kodowe większości z Was nic nie mówi, więc przytoczę tu pełną nazwę którą jest “Java Servlet 3.0 Specification”. Tak, dokładnie specyfikacja oznaczona jako JSR 315 dotyczy niczego innego jak właśnie nowej wersji servletów, oznaczonej numerem 3.0.
Nowa wersja nową wersją i różnie to wygląda w przypadku różnych technologii, jednak wydaje mi się, że zmiany które będą wprowadzone w ramach kolejnej wersji servletów są na tyle istotne, iż warto je tutaj przybliżyć.

Servlety 3.0 wniosą powiew świeżości, oto część zmian jakie nadchodzą:

użycie adnotacji do konfiguracji servletów i filtrów
“web fragments”, czyli dotychczasowa konfiguracja web.xml z wykorzystaniem wielu plików
metody do dodawania servletów i filtrów
asynchroniczne przetwarzanie

Opiszę teraz pokrótce poszczególne z nich:

Użycie adnotacji do konfiguracji servletów i filtrów

Tak naprawdę oprócz konfiguracji servletów i filtrów możemy również skonfigurować listenery.
Pakiet zawierający potrzebne adnotacje nosi nazwę javax.servlet.annotation.
Znajdują się w nim m.in. następujące adnotacje:

@WebServlet
@ServletFilter
@WebServletContextListener

Oczywiście servlety, filtry jak i listenery muszą implementować/rozszerzać odpowiednie interfejsy/klasy (tak jak to było do tej pory), zespół pracujący nad tą specyfikacją planował wcześniej zrezygnować z konieczności rozszerzania klasy javax.servlet.http.HttpServlet na rzecz samego oznaczenia klasy servletu adnotacją @Servlet (obecnie jest @WebServlet)oraz dostarczenia metod przyjmujących jako parametr HttpServletRequest oraz HttpServletResponse. Oczywiście w takim przypadku konieczne byłyby dodatkowe adnotacje jak np. @GET czy też @POST w celu oznaczenia czy dana metoda zdefiniowana w ramach servletu obsługuje odpowiednią metodę HTTP. Wcześniejsze podejście umożliwiało w ten sposób zastosowanie zwykłych klas POJO jako klas servletów. Nie jestem do końca przekonany do takiego podejścia, nie to żebym był tradycjonalistą, jednak taka elastyczność wydaje mi się zbędna w tym przypadku w dodatku wprowadza pewien ład. Wracając jednak do adnotacji to będą one obok standardowego pliku web.xml drugim sposobem na definicję parametrów servletu, servlet w ten sposób oznaczony będzie automatycznie wykrywany (oczywiście o ile będzie się znajdował w classpath) przez kontener servletów zgodny ze specyfikacją Java Servlet 3.0. Warto tu nadmienić, iż wzorcową implementacją (RI - reference implementation) kontenera zgodnego z tą specyfikacją ma być Glassfish w wersji 3 (to chyba nikogo nie dziwi).

Aby obrazowo przedstawić zastosowanie adnotacji @WebServlet proponuję spojrzeć na poniższy przykład:

@WebServlet(
name=“sampleservlet”,
urlPatterns={“/sampleservlet”},
initParams={
@InitParam(name=“paramname”, value=“paramvalue”)
}
)
public class TestServlet extends javax.servlet.http.HttpServlet {
//tu kod servletu
}

Jak widzicie w powyższym przykładzie zdefiniowałem nazwę servletu “sampleservlet” oraz mapowanie “/sampleservlet“, podałem też przykładowy parametr który może zostać użyty przy inicjalizacji servletu. Tak zdefiniowany servlet musimy umieścić w zasięgu naszego classpath, kontener zgodny ze specyfikacją 3.0 servletów powinien sam wykryć taki servlet i go odpowiednio zainicjować. Oczywiście można wyłączyć obsługę automatycznego wykrywania servletów, filtrów czy też listenerów, jest to jednak całkiem wygodna opcja, którą z uwagi na bezpieczeństwo powinno się używać z rozwagą.

Web fragments

Pewnie nie raz spotykaliście się z przydługawymi plikami web.xml (tzw. deskryptory aplikacji), w których skonfigurowana była cała masa servletów, filtrów, listenerów.
Obsługa takiego pliku może niejednokrotnie przysporzyć problemów, dodatkowe problemy pojawiają się
gdy chcemy skonfigurować jakiś framework, którego jeszcze nie znamy.
Tutaj z pomocą przyjdzie nam JSR 315 i tzw. “web fragments”. Pewnie już domyślacie się do czego to służy? Otóż web fragments mają w zamiarze umożliwić dzielenie konfiguracji która znajduje się w jednym pliku konfiguracyjnym na wiele “fragmentów”, z których zostanie wczytana kompletna konfiguracja.
W praktyce oznacza to, iż we frameworkach takich jak np. Struts 2 a właściwie w ich archiwum JAR będzie można umieścić taki fragment deskryptora. Tak umieszczony fragment będzie mógł zostać wykryty przez kontener servletów i odpowiednio wykorzystany np. do domyślnej konfiguracji frameworku. Oczywiście będzie tu przyjęta odpowiednia konwencja, plik taki musi się nazywać web-fragment.xml, musi być też umieszczony w katalogu META-INF biblioteki.
Prawda, że przyjemne? A jak to jeszcze ułatwi życie Oczywiście może się tutaj pojawić problem z bezpieczeństwem jak automatyczna inicjalizacja rzeczy o których moglibyśmy sobie nie zdawać sprawy.

Kolejna rzecz to:

Metody do dodawania servletów i filtrów

Tak, będziemy mogli użyć specjalnych metod, których przeznaczeniem będzie inicjalizacja np. servletu.
Będą to metody addServlet oraz addFilter.

Czas na ostatnią z wymienionych powyżej nowości (oczywiście znajdziecie tego więcej na stronie specyfikacji), a mianowicie:

Asynchroniczne przetwarzanie

To jedna z najważniejszych zmian w porównaniu do wersji 2.5. Znacie dobrze te sytuacje w których Wasz servlet musi wywołać wywołanie usługi sieciowej albo przeprowadzić jakąś inną operację zajmującą więcej czasu, w takie sytuacji klient wywołujący servlet musi czekać aż operacja zostanie wykonana. Właśnie w takim przypadku przydaje się wywołanie asynchroniczne, i tutaj okazuje się, że twórcy specyfikacji 3.0 servletów wprowadzają do niej asynchroniczne przetwarzanie. Ale jak to ma wyglądać w praktyce? Obecna wersja specyfikacji wprowadza pojęcie kontekstu wywołania asynchronicznego, reprezentowanego przez klasę AsyncContext zawiera on informacje o otrzymanym żądaniu i odpowiedzi. Oczywiście w celu użycia wywołania asynchronicznego na servlecie należy go odpowiednio skonfigurować, czyli ustawić jeden atrybut o nazwie supportAsync, tak skonfigurowany servlet (lub filtr) będzie mógł już służyć do obsługi wywołań asynchronicznych. Ponieważ po wykonaniu operacji przez servlet może się okazać konieczne wykonanie dodatkowych czynności, autorzy specyfikacji JSR 315 wprowadzają nowy rodzaj interfejsu listenera AsyncListener którego implementację należy dodać do requestu. Implementacja taka będzie posiadała co najmniej dwie metody o nazwach onComplete oraz onTimeout (zdefiniowane w ramach interfejsu), pierwsza zostanie wywołana w przypadku zakończenia przetwarzania requestu na czas, druga w przypadku gdy wystąpi timeout (wartość timeoutu w milisekundach podamy w parametrze servletu o nazwie asyncTimeout).

To wszystko w tym wpisie, więcej informacji na temat Java Servlet 3.0 Specification znajdziecie na stronie Java Community Process.

February 8, 2009 | |

COMMENTS

Trackback URI | Comments RSS

3 Responses to “Java Servlet 3.0 Specification czyli nadchodzą zmiany…”

Jacek Laskowski on February 10th, 2009 10:46 am

Dzięki! I już wiem, co w Servlet3 się dzieje. Pewnie czytając specyfikację zajęłoby mi to cały dzień, a tu niecałe 5 minut. Jakby tak jeszcze o Scali poczytać…
radoslaw.holewa on February 10th, 2009 10:01 pm

Mimo wszystko zachęcam do poczytania specyfikacji

Co do Scali to niestety siedzę nad nią w pracy i po pracy ale brak mi sił na pisanie postów na blogu. Jednak pisząc posty trzeba trochę czasu na to poświęcić a ja jakoś nie mogę się przekonać do tego żeby pisać - wolę poczytać coś albo kodować

Może jednak coś napiszę dla przykładu, np. coś o przetwarzaniu XMLi w Scali, która ma wsparcie do tego w konstrukcji samego języka

Na koniec dzięki za nakłanianie do pisania
Bartosz Leper on February 22nd, 2009 7:59 pm

Też myślę, że zdecydowanie najważniejszą zmianą jest wprowadzenie przetwarzania asynchronicznego. Pozostałe opisywane przez Ciebie zmiany są również istotne i wniosą odrobinę “świeżego powietrza” do starego, dobrego JEE, ale zauważ również, że są to zmiany o charakterze udogodnień, których brak da się obejść na poziomie aplikacji. Za to interfejs asynchroniczny to zmiana przełomowa; do tej pory nie było możliwości “oddania” wątku kontenerowi na czas oczekiwania na odpowiedź systemu, od którego zależny jest serwlet.

O ile oczywiście dobrze rozumiem w jaki sposób ma to działać.