JAVA EE6 Programowanie aplikacji WWW KURS cz. 8 Wprowadzenie do JSP

     


      JSP - JavaServer Pages jest to technologia, która umożliwia zagnieżdżenie kodu Java w dokumentach HTML. Wcześniej skupialiśmy swoją uwagę na mechanizmie działania serwletów. Generowanie kodu HTML z wykorzystaniem metody println() obiektu PrintWriter. Takie podejście bardzo komplikuje kod i utrudnia korzystanie z narzędzi do tworzenia dokumentów HTML. Podział pracy między tworzeniem wizualnej strony, a tworzeniem logiki jest zachwiany. Odpowiedzią na powyższą wadę serwletów było opracowanie przez firmę Sun technologii JavaServer Pages.



      JSP pozwala nam na wstawianie do zwykłego kodu HTML konstrukcji w języku Java - co nie jest obecnie zalecane. Umieszczanie kodu Java w dokumencie HTML odbywa się z wykorzystaniem specjalnych znaczników.

      Takie umieszczenie konstrukcji językowych Java w dokumencie JSP nazywamy skryptami. Nie powinniśmy stosować takiego rozwiązania, ponieważ jak wiemy JSP zostało stworzone w celu uniknięcia niewygodnego generowania stron HTML z wykorzystaniem serwletów, a także do rozdzielenia mechanizmów aplikacji webowej czyli warstwy logiki aplikacji od warstwy prezentacji. Skryplety burzą ten podział. Powiedzmy sobie po prostu, że jest to przeszłość. Zamiast nich powinniśmy używać specjalnych znaczników EL i JSTL. Wspomniałem kiedyś, że JSP to tak naprawdę serwlet. Od strony technicznej dokument JSP przy pierwszym uruchomieniu jest przekształcany na serwerze do odpowiadającego im serwletu.

 

       

       Klient wysyła żądanie pobrania strony, które po przejściu przez serwer HTTP trafia do serwera aplikacji - Web server. Żądanie zostaje przekierowane do kontenera JSP, który znajduje się na serwerze aplikacji. Podczas pierwszego żądania pobrania strony JSP zostaje ona wysłana do translatora JSP. Translator generuje kod wynikowy w postaci klasy serwletu. Kod źródłowy jest przesyłany do kompilatora Java, gdzie zamieniamy jest na Java Byte Code maszyny wirtualnej. Od tej pory ten skompilowany kod czyli tak naprawdę serwlet jest zarządzany przez kontener serwletów.

Skompilowane strony JSP pozostają załadowane do maszyny wirtualnej Java i kolejne odwołania do tej samej strony nie wymagają przejścia przez fazę translacji.

      Obecnie technologia JSP ma wsparcie w postaci języka wyrażeń EL- Expression Language i standardowej biblioteki znaczników JSTL - JavaServer Pages Tag Library.EL i JSTL zastępują nam znaczniki, które za bardzo komplikują kod, a także mieszają logikę prezentacji i aplikacji.

Strony JSP mogą odwoływać się do obiektów predefiniowanych w skryptach :

• request - wszystkie parametry wywołania strony JSP (HttpServletRequest)
• response - reprezentuje odpowiedź zwracaną klientowi (HttpServletResponse)
• out - reprezentuje stronę zwracaną klientowi (jsp.JspWriter)
• session - reprezentuje sesję HTTP (http.HttpSession)
• application - reprezentuje kontekst aplikacji (ServletContex)
• config - konfiguracja serwletu (servletConfig)
• pageContext - obiekty, które są w zasięgu widoczności bieżącej strony (jsp.PageContext)
• page - reprezentuje bieżącą stronę (java.lang.Object)

      Przyjrzyjmy się skryptom JSP, których jak już wspomniałem nie należy używać. Skrypty są to :

• <%= wyrazenie  %> - wyrażenia są one przekazywane na wyjście czyli okno przeglądarki
• <% kod %> - skryplety są umieszczane wewnątrz metody service() serwletu
• <%! kod %> - deklaracje są umieszczane wewnątrz klasy serwletu poza metodami

      Przykład wyrażenia: Przykład skrypletu: Przykład deklaracji:       JSP dostarcza dyrektyw czyli kilku różnych konstrukcji stosowanych w zależności od danej sytuacji. Istnieją ogólnie trzy główne typy dyrektyw:

• page - pozwala m.in. na importowanie klasy, określić język użyty w skryplecie itp.
• include - pozwala na dołączenie innego pliku do treści danej strony
• taglib - jest związana z technologią JSTL, której przyjrzymy się później po omówienie EL

      Przykład dyrektywy page:

      Jak widzimy dyrektywa taka posiada pewne atrybutu, nie są to wszystkie atrybuty jakie może przyjąć.

      Oto najważniejsze ustawienia dyrektywy page:

• contentType - określa typ MIME strony np. text/html
• pageEncoding - kodowanie znaków na stronie
• isErrorPage - określa czy dana strona jest stroną błędu
• errorPage - określa ścieżkę do strony, która ma być wywołana  w razie błędu na tej stronie
• session - określa czy na danej stronie jest wykorzystywane mechanizm sesji
• import - pozwala na importowanie klas/pakietów, w celu późniejszego wykorzystania 
• isELIgnored - określa, czy elementy języka wyrażeń EL mają być ignorowane na danej stronie

      Stwórzmy bardzo prostą aplikację w środowisku NetBeans. Klient wchodząc na stronę poda swoje imię i hasło w formularzu, po zatwierdzeniu danych zostaje wyświetlona strona z imieniem i datą logowania.

      Stwórzmy na początku stronę odpowiadająca za pobranie danych od użytkownika, nazwijmy ją loginpage.jsp:

      Strona index.jsp zostanie zmodyfikowana w ten sposób, aby wyświetlała login, który podał klient. Strona wykorzystuje bibliotekę JSTL, powiemy sobie o niej następnym razem. Następuje odczyt w pętli atrybutów sesji. Atrybut ma nazwę User i odwołujemy się do niego przez sessionScope.User .User jest kolekcją zawierającą obiekty klasy User. Zmienna var="user" przechowuje pobrany obiekt z kolekcji. Wyświetlenie nazwy użytkownika i daty logowania odbywa się bardzo prosto: ${user.name} ${user.t} .
 



       Stworzymy też serwlet odpowiedzialny za pobranie danych z formularza i przekierowania żądania do strony index.jsp. W serwlecie korzystamy z mechanizmu sesji. Zapisujemy w niej kolekcję przechowującą obiekty klasy User. Po tym następuje przekierowanie żądania do strony index.jsp.



      Obiekt klasy User będzie odzwierciedlać klienta, przechowując jego login, hasło i datę logowania. Taka klasa, która spełnia kilka konwencji głównie  takich jak bez parametryczny konstruktor, udostępnianie atrybutów po przez metody pośredniczące get i set nazywamy JavaBean - ziarno kawy. Jak spojrzymy na nasz serwlet to zauważymy, że ustawiamy w zasięgu sesji atrybut o nazwie User będący kolekcją typu ArrayList, przechowującą obiekty klasy User.

     


Pozostaje, także do skonfigurowania deskryptor wdrożenia:




   
 Nasza aplikacja wygląda w następujący sposób:

      Formularz logowania:

 

      Strona index.jsp, która reprezentuje wprowadzone dane:

   

      W następnych częściach przyjrzymy się EL - językowi wyrażeń, JavaBeans - ziarna kawy, akcjom JSP, standardowej bibliotece tagów JSTL, modelowi JSP 1 i JSP 2 czyli wzorcowi MVC.

Read More

JAVA EE6 Programowanie aplikacji WWW KURS cz. 7 Serwlety: kontener, kontekst i filtry

      Kontekst serwletów jest obiektem służącym do komunikacji serwletów z kontenerem.
Głównym zadaniem kontenera jest obsługa komunikacji między serwletami, a serwerem. Zarządza on cyklem życia serwletów, tworzy nowy wątek obsługujący żądanie. Kontener, także zajmuje się obsługą JSP, strony JSP tak naprawdę są serwletami.

      Kontener obsługując konkretne żądanie, które skierowane jest do serwletu po przez adres URL, tworzy dwa obiekty: HttpServletResponse i HttpServletRequest. W następnym kroku tworzy lub przydziela pamięć dla wątku, który obsługuje to żądanie. Obiekty reprezentujące żądanie i odpowiedź są przekazane do nowego wątku serwletu. Od tej pory mamy już gotowy serwlet. Następuje wywołanie metody service() serwletu. Metoda ta wywołuje metodę doGet() lub do Post(), w zależności naszego żądania. Jeśli nasze żądanie było typu GET to następuje jak się domyślasz wywołanie metody doGet().

     Dzięki kontekstowi serwletów możemy dynamicznie dodawać serwlety do aplikacji, a co najważniejsze korzystać z parametrów aplikacji webowej czyli kontekstu. Wcześniej pisałem o parametrach serwletów. Są one widoczne w ramach danego serwletu. Parametry konteksu są widoczne dla wszystkich serwletów w naszej aplikacji. Określamy je w bardzo podobny sposób co parametry serwletów:



Aby skorzystać z parametrów kontekstu musimy skorzystać z metody: getInitParameter(String name)




      Przejdźmy do filtrów. Filtry są mechanizmem umożliwiającym nam wykonanie operacji w momencie nadejścia żądania. Dzięki nim możemy np. odrzucić dane żądanie, które nie spełnia jakiś określonych parametrów. Filtry możemy podłączać do dowolnej grupy serwletów za pomocą znacznika url-pattern. Analogicznie do serwletów są deklarowane w deskryptorze wdrożenia. Kontener na podstawie znacznika url-pattern decyduje kiedy zostanie wywołany dany filtr. Kiedy ma być obsłużone żądanie, najpierw kontener przeszuka pasujące do adresu URL filtry i wywoła je, w takiej kolejności w jakiej są zadeklarowane w deskryptorze. Możemy mówić wtedy o sekwencji wywołań.

       Z technicznego punktu widzenia filtr jest klasą, która implementuje interfejs javax.servlet.Filter. Udostępnia on nam metody:

• void init(FilterConfig fc) - metoda wywoływana jest przy utworzeniu filtru. Pozwala na uzyskanie obiektu interfejsu FilterConfig odpowiedzialnego za ustawienia filtru.
• void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) - jest wywoływana w momencie nadejścia żądania. Interfejs FilterChain zapewnia komunikację pomiędzy filtrem, a servletem. 
• void destroy() - metoda wywoływana przez serwer w momencie zakończenia działania filtru.

      W zależności od kolejności deklaracji filtrów w deskryptorze - web.xml, nasze żądanie HTTP przechodzi przez kolejne filtry dzięki metodzie doFilter(), w każdym filtrze. Po przejściu wszystkich filtrów, żądanie trafia do serwletu. Po zakończeniu obsługi żądania przez serwlet, sterowanie powraca do kolejnych filtrów.


       Stworzymy teraz bardzo prosty filtr. Zadaniem filtra będzie mierzenie czasu wykonania żądania.
Wspomnieliśmy wcześniej, że filtr to klasa implementująca interfejs Filter. Nasze żądanie zanim trafi do servletu, najpierw trafia do naszego filtru. Kiedy zostaje wykonywana metoda doFilter() zmiennej startTime przypisywany jest aktualny czas, następnie zostaje znowu wykonana metoda doFilter() z obiektu chain. Po jej wykonaniu nasze żądanie, przechodzi do właściwego  serwletu, gdzie po jego obsłużeniu znowu trafia do filtra, w miejsce po wywołaniu metody doFilter(), gdzie pobierany jest do zmiennej stopTime aktualny czas. Aby obliczyć czas wykonania żądania wystarczy te wartości od siebie odjąć.



      Tak jak w przypadku serwletów filtry konfigurujemy podobnie. Mamy dwie sekcje. Znacznik filter ,który wiąże klase filtru z abstrakcyjną nazwą i znacznik filter-mapping wiążacy nazwę z adresem URL.




Ciekawostką jest znacznik dispatcher . Pozwala on określić, czy filtr ma być stosowany w innych przypadkach niż w bezpośrednich żądaniach.

Read More

JAVA 7 - czyli kilka drobnych nowości.

Na nową odsłonę JSE trzeba było poczekać nam około pięciu lat. Java Standard Edition 7 jest to pierwsze wydanie od czasu przejęcia Sun przez Oracle. Nowa wersja nie jest rewolucyjna jeśli chodzi o nowe zmiany. Jest to kolejna ewolucja JSE opatrzona  numerem - 7. Termin upublicznienia nowej wersji był nie raz zmieniany, powodem tego było pewnie przejęcie Sun'a przez Oracle'a.








Na stronie: http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html możemy zobaczyć szczegółową listę zmian.

Do najważniejszych zmian w nowej edycji JSE możemy zaliczyć między innymi :

• Garbage First - nowy udoskonalony garbage collector w maszynie wirualnej HotSpot
• Dla maszyn o architekturze 64-bitowej "skompresowany" 64-bitowy wskaźnik
• Biblioteka Fork/Join czyli lepsza obsługa procesorów wielordzeniowych i wielowątkowości
• Projekt Coin - udogodnienia na poziomie składniowej języka(zmniejszenie objętości kodu). Kompilator automatycznie zamyka pliki, gniazda itp.
• Poprawiona obsługa operacji I/O.
• Udoskonalone wsparcie dla języków dynamicznych

      Garbage Collector zarządza pamięcią w JAVIE. Jest to mechanizm, który zwalnia pamięć z nieużywanych obiektów. Działa on niejawnie czyli w tle aplikacji. Jest on nie raz częstą przyczyną spowolnienia naszych programów. Strojenie tego mechanizmu jest bardzo trudne, ponieważ istnieje około 200 parametrów GC. W związku z tym w wydaniu JDK 6 update 14 mamy dostępny nowy eksperymentalny Garbage First. Jest on przeznaczony według twórców do systemów serwerowych, wielowątkowych używających duże ilości pamięci. Nowy mechanizm tak jego poprzednicy jest równoległy, współbieżny i pokoleniowy. Wyróżnia go kompaktowanie sterty, czyli mała fragmentacja pamięci.Sterta podzielona jest na obszary o rozmiarze 1MB. Możemy, także "powiedzieć mu" przez jaki okres czasu ma działać. Jest łatwiejszy w użyciu.
      W poprzednich wersjach GC obszary pamięci, w których są obiekty młode i stare mają stałą wielkość. W nowym Garbage Collector regiony na które jest podzielona pamięć mogą wchodzić w skład pokolenia młodego lub starego i jest to dynamicznie zmieniane w czasie działania aplikacji.
      W maszynach 32-bitowych do dyspozycji mamy 2^32 = 4GB przestrzeni adresowej, a maksymalny rozmiar sterty zależy od systemu operacyjnego. W 64- bitowej maszynie wirtualnej rozmiar ten jest tak duży, że praktycznie możemy nie przejmować się nagłym brakiem dostępnej pamięci. Wadą 64-bitowej maszyny wirtualnej jest zwiększenie zużycia pamięci. Wynika to ze zwiększenia nagłówków obiektów, większego rozmiaru wskaźników do innych obiektów. Garbage First oferuje nam skompresowany 64-bitowy wskaźnik, dzięki temu różnica w zużyciu pamięci między 32-bitową, a 64-bitową platformą staje się dużo mniejsza. Skompresowany wskaźnik jest 32-bitowym offsetem od początku sterty, dlatego w przypadku sterty większej niż 32Gb maszyna wirtualna używa "pełnych" 64-bitowych wskaźników.


      Framework fork/join jest implementacją interfejsu ExecutorService. ExecutorService jest rozszerzeniem interfejsu Executor, zarządza on cyklem życia wątków, a także śledzi postęp wykonywanego zadania. Fork/Join ma  pomóc programiście w wykorzystaniu wielu procesorów. Jest zaprojektowany dla zadań, które możemy podzielić na mniejsze kawałki. Framework ten dystrybuuje zadania do działających wątków w puli wątków. Używa on algorytmu wykradania zadań (work-stealing). Działające wątki, którym zabraknie zadań, mogą je "ukraść" od innych, które są w tym czasie zajęte. Centralną częścią frameworka jest klasa ForkJoinPool rozszerzająca abstrakcyjną klasę AbstractExecutorService. Klasa implementuje algorytm wykradania zadań i może wykonać ForkJoinTasks(są to "lekkie wątki ").

     Zasada działania użycia tego frameworka jest bardzo prosta. Jeśli nasz kod wykonuje jakieś zadanie, ze względu na jego duży rozmiar możemy go podzielić na mniejsze kawałki. Przykład ze strony Oracle'a jest prosty. Mamy za zadanie wykonać rozmycie obrazy tzw. blur. Obraz jest reprezentowany przez tablicę liczb, gdzie każda liczba zawiera składowe koloru pojedynczego pixela. Obraz rozmyty będzie, także reprezentowany w takiej samej postaci. Poniższy kod przedstawia realizację rozmycia obrazu:



Teraz pora na implementację abstrakcyjnej metody compute(), która wykonuje rozmycie obrazu bezpośrednio lub dzieli go na dwa mniejsze zadania. Od tego czy zadanie będzie podzielone zależy rozmiar tablicy.




Na poziomie samego języka mamy kilka udogodnień. Java 7 wprowadza literały binarne. Pozwalają na zapisywanie typów takich jak: byte, short, int i long za pomocą systemu binarnego.



Nowością jest możliwość użycia znaku podkreślenia.



Dla wygody zaimplementowana została możliwość użycia String w konstrukcji switch-case:



Diamond. Nie musimy dwukrotnie podawać typu elementu w klasach wykorzystujących typy ogólne - generics.



Łapanie kilku wyjątków w jednym bloku catch:



Automatyczne zarządzanie zasobami. Dzięki niemu zasoby zdefiniowane w bloku try będą dostępne, a po jego zakończeniu zostaną automatycznie zamknięte. Java 7 oferuje interfejs AutoCloseable, posiada on metodę close(), która odpowiada za zamknięcie zasobu.



Klasa java.io.File nie dawała nam takich metod, które odpowiedzialne były by za kopiowanie lub przenoszenie plików. Poza tym miała problemy z wydajnością przy obsłudze "dużych" katalogów. Java 7 wprowadza udoskonalone API dostępu do systemu plików. Nowe pakiety java.nio.file, java.nio.file.attribute oferują nam więcej możliwości. Być może opisze je następnym razem.

Read More