GeeCON - czy Twój szef wystarczająco dba o Ciebie?

Filed Under Category Grails, Java, Konferencje, PJUG, SAI, Struts 2 by radoslaw.holewa

Tytuł może zbyt kontrowersyjny ale w innym przypadku pewnie nie zwrócilibyście na niego uwagi :)

Jak zapewne większość z Was wie, wczoraj wystartowaliśmy z rejestracją na GeeCON - pierwszą w pełni międzynarodową konferencją poświęconą Javie w Polsce. Jest to dobry moment aby przybliżyć pokrótce powody dla których ją organizujemy oraz dlaczego poważnie powinieneś zastanowić się nad udziałem w GeeCON.

Po pierwsze, głównym powodem dla którego zabraliśmy się za organizację GeeCON była chęć umożliwienia Wam i sobie udziału w konferencji podczas której prelegentami będą ludzie z naprawdę topową wiedzą. Część z nich to znane osoby pracujące nad rozwojem technologii których używacie codziennie w pracy, część to ludzie pracujący nad ciekawymi projektami, którzy są chętni podzielić się swoim doświadczeniem. Staramy się ich zebrać w jednym miejscu i czasie, tak aby stworzyć możliwie najbardziej interesujące wydarzenie “javowe” w tym roku w Polsce.

Oczywiście, nie wszystkie tematy muszą wszystkim odpowiadać, możliwe też, że część z prezentacji, które znajdują się w agendzie byłaby Waszym zdaniem gorsza od tych, które musieliśmy odrzucić z braku wolnych slotów (aktualne wolne sloty w agendzie są przeznaczone dla prelegentów, którzy nie śpieszą się z podsyłaniem tematów i abstraktów).

Organizując GeeCON staramy się unikać tego czego sami nie lubimy, dlatego też ograniczyliśmy do absolutnego minimum wszystkie marketingowe aspekty prezentacji, a prelegenci sponsorów będą opowiadać o rozwiązaniach open source i technologiach ogólnie dostępnych, to jest jeden z naszych głównych celów.

Pomimo faktu, że wszyscy organizujemy konferencję za free (ot taki rodzaj wolontariatu), nie uda nam się doprowadzić do tego aby wejściówki były za darmo. Niestety są pewne koszty stałe, których pokrycie konieczne jest do realizacji pełni naszej wizji. Gdybyśmy z nich zrezygnowali to GeeCON nie byłby już GeeCONem w tej postaci jaką możecie obserwować (byłby krótszy i z udziałem mniejszej ilości zagranicznych prelegentów oraz z dużym udziałem prezentacji marketingowych).

Na całe szczęście udało nam się zminimalizować stawkę do poziomu, który część osób naprawdę zadowala (pozostałe zawsze będą narzekać, że jest zbyt drogo :P). 389 PLN to chyba stawka do przełknięcia dla wszystkich firm informatycznych w kraju i dla większości developerów (już nie narzekajcie jak to mało zarabiacie), w ten sposób prawdopodobnie odrzucamy główny argument Waszego PM’a, który pewnie zawsze mówi Wam, że wyjazd na zagraniczne konferencje to zbyt duży koszt :)

Faktycznie porównując z takimi konferencjami jak QCon, Jazoon czy też ApacheCon to GeeCON jest śmiesznie tani. Oczywiście wiadomo, że te konferencje są sporo większe od GeeCON ale z drugiej strony i tak możecie uczestniczyć w jednej ścieżce w jednej chwili co sprawia, że w przeliczeniu na godzinę prezentacji GeeCON to zdecydowanie mniejszy koszt. I o to właśnie wszystkim organizatorom chodziło, nie organizować imprezy dla zysku a tylko dlatego aby dostarczyć Wam godne uwagi wydarzenie “javowe”.

Jeśli już dotarliście do tego miejsca to mam nadzieję, że podzielicie się swoimi uwagami i spostrzeżeniami, zarówno jeśli chodzi o GeeCON, jak i inne rzeczy które mogą się Wam wydać istotne w kontekście tego wpisu. Na koniec jeszcze chciałem wszystkich zaprosić do udziału w GeeCON i nie tylko, bo już wielkimi krokami zbliża się kolejna Javarsovia i Java4People :)

February 27, 2009 | 3 Comments 

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 | 3 Comments