Wielokrotnie wchodząc na przeróżne strony zamiast oczekiwanej przeze mnie treści pojawiała się strona z błędami aplikacji, i nie był to tylko komunikat w stylu „Błąd strony” a pełne kody błędów, łącznie ze stacktracem czy też kodem strony (jeśli była pisana w języku skryptowym). Nie trzeba chyba nikomu tłumaczyć, że tego typu treść nigdy nie powinna być widoczna dla użytkownika końcowego. I nie tylko dlatego, że strona taka brzydko wygląda i może odstraszyć użytkowników. Treści wyjątków jakie powoduje aplikacja, czy też część kodu jakie pojawią się mogą być bez problemu wykorzystane przez osoby interesujące się zabezpieczeniami.

W bibliotece SpringFramework, istnieje coś takiego jak ExceptionHandler, który działa lokalnie i jest implementowany per kontroler co przy większej aplikacji może być mało wygodne. Niestety globalny mechanizm przechwytywania powstanie najwcześniej w wersji 3.2(kiedyś przeczytałem pewien komentarz programisty Springa w ich systemie Jira) więc puki co musimy radzić sobie sami. Prosty system przechwytujący wyjątki można napisać samemu i nawet specjalnie się przy tym nie napracujemy.
Do stworzenia takiego systemu będziemy potrzebować najnowszych bibliotek Springa oraz bibliotek wspomagających programowanie aspektowe (aspectjweaver)

Na początek skonfigurujemy klasę która będzie obsługiwać wyjątki, konfigurację umieszczamy w applicationContext.xml

</pre>
<aop:aspectj-autoproxy />
 <aop:config>
 <aop:aspect id="exceptionHandler" ref="globalExceptionHandler">
 <!-- find all methods that returns ModelAndView objects -->
 <aop:pointcut expression="execution(org.springframework.web.servlet.ModelAndView+ *(..))" id="returningMav" />
 <!-- and execute them inside exceptionHandler -->
 <aop:around method="exceptionHandler" pointcut-ref="returningMav" />
 </aop:aspect>
 </aop:config>
 <bean id="globalExceptionHandler" class="com.darekzon.spring.exhandler.aop.ExceptionHandler" />
<pre>

Powyższy zapis konfiguruje system tak aby wyłapał wszystkie metody zwracające obiekt „ModelAndView” (czyli zazwyczaj metody mapujące URL-e) i przekazywał je do naszego obiektu, a dokładniej do metody „exceptionHandler” w klasie „ExceptionHandler”.
Metody te będą przekazywane w formie obiektu ProceedingJoinPoint posiadającego metodę „proceed” która służy do wywołania domyślnej akcji.

Nasza metoda obsługująca wyjątki wygląda jak poniżej

public ModelAndViewexceptionHandler(ProceedingJoinPoint pjp)throws Throwable{
        ModelAndView mav=newModelAndView();
        try{
            mav=(ModelAndView) pjp.proceed();
        }catch(Exceptionae){
            mav.addObject("exceptionMessage",ae.getMessage());
            mav.setViewName("exception");
        }
        return mav;
    }

Działanie jest proste, wywołaj metodę która może rzucić wyjątek (tj. metodę obsługującą url) i jeśli taki wyjątek zostanie rzucony, złap go, dodaj jego wiadomość do widoku jako ‘exceptionMessage’ oraz wygeneruj widok o nazwie ‘exception’. A co za tym idzie, jeśli nasza metoda kontrolera wyrzuci wyjątek, zostanie on złapany a zamiast niego zostanie zwrócony poprawny obiekt ModelAndView.

Oczywiście zamiast prostej podmiany widoków możemy przekierować użytkownika do innej strony, zapisać logi, czy też wysłać maila.

Działający projekt

Działający projekt można pobrać przeglądać pod adresem https://github.com/darek/spring.3.examples/tree/master/aop-global-exception-handler

Firma Jetbrains znana z wysokiej jakości środowisk programistycznych (IDE) postanowiła kilka dni temu wypuścić kod źródłowy swojego flagowego produktu. Kod źródłowy został umieszczony na serwerach GitHuba w ramach konsolidacji projektów open-source-owych prowadzonych w firmie.

Na serwerach GitHuba dostępna jest wersja Community Edition która posiada pełne wsparcie dla języków Java, Groovy, Xml, Sala, Clojure (dwa ostatnie po zainstalowaniu darmowych wtyczek), a także posiada GUI builder, integrację frameworków testujących (JUnit oraz TestNG) oraz wsparcie dla Maven-a i Ant-a. Dla tych którzy wolą programować aplikacje mobilne zaimplementowane jest wsparcie platformy Android, a dla pracujących w grupie przewidziane jest wsparcie systemów kontroli wersji CVS, Subversion, Git (wraz z integracją GitHub-a) oraz Mercurial. Jeśli nie macie gdzie publikować swoich źródeł polecam BitBucket który ostatnimi czasy przeszedł małą modernizację.

Niestety w tych wszystkich wspaniałościach zabrakło dla mnie najważniejszej rzeczy, czyli pełnego wsparcia dla frameworków webowych (JSP, Spring, Hibernate, etc.) które to są dostępne dopiero w płatnych edycjach.

Gdyby ktoś tak jak ja potrzebował funkcjonalności nie zawartych w wersji Community może wybrać wersję Ultimate i skorzystać z nowych cen jakie zaproponował Jetbrains, za najtańszą wersję (Personal License) zapłacimy 175€ czyli o 44€ mniej (poprzednia cena 219€), natomiast licencja dla firm i organizacji (Commercial License) to wydatek rzędu 439€ o 88€ mniej (poprzednia cena 527€). Oczywiście możliwe jest też otrzymanie licencji na wersję Ultimate za darmo o ile prowadzimy w miarę popularny projekt Open Source.

Ponieważ od jakiegoś czasu zdobywam wiedzę na temat nowych frameworków i technologii postanowiłem stworzyć właśnie projekt który integruje je wszystki. Wykorzystam w nim frameworki Guice oraz Struts2, a za przechowywanie danych odpowiadać będzie MongoDB wspierana przez bibliotekę Morphia. Dodatkowo z racji, że ostatnio co chwile mówi się o aplikacjach REST-owych postanowiłem wykorzystać ten wzorzec w mojej aplikacji – „liście zakupowej„.

Skąd pobrać projekt

Projekt dostępny jest w formie repozytorium GIT pod adresem https://github.com/darek/struts2-rest-shopping-list

Struts2 oraz Guice

Jeśli ktoś nie zna frameworka Struts2 to wspomnę tylko, że jest to jeden z bardziej popularnych bibliotek do tworzenia aplikacji JEE. Cechuje się elastycznością oraz rozszerzalnością (poprzez pluginy).
Guice jest dość świeży na polu frameworków, służy do wstrzykiwania zależności, a jego twórcami są inżynierowie Google.

MongoDB

Jak wspomniałem na wstępie MongoDB to baza danych oparta o dokumenty, oznacza to tyle, że dane w niej zawarte nie reprezentowane są w formie tabel posiadającej sztywny schemat a raczej w formie łatwo rozszerzalnego dokumentu (wykorzystywany jest tu format BSON). Największą zaletą (prócz łatwej skalowalności i wydajności) jest brak schematu, możemy wrzucić do niej co tylko chcemy bez potrzeby aktualizacji struktur tabel, każdy dokument nawet jeśli jest w tej samej kolekcji może się różnić od innych. Dokumenty te jednak nie posiadają powiązań więc trudniej jest zaimplementować schemat typu jeden do wielu, wiele do wielu. Pomimo tego baza ta idealnie nadaje się do mojej aplikacji. W końcu każda lista zakupowa posiada swój własny zestaw produktów do kupienia, nie potrzebujemy tu oddzielnej tabeli do składowania produktów.

REST

Od dłuższego czasu coraz większą popularność zyskuje wzorzec architektury zwany REST (Representational State Transfer) zaproponowany przez Roya T. Fieldinga w publikacji Principled Design of the Modern Web Architecture. W wielkim skrócie chodzi o takie przygotowanie aplikacji by zasoby którymi operuje były dostępne pod unikalnymi linkami (URI), czyli żeby wyświetlić szczegóły użytkownika naszej aplikacji wykorzystamy adres http://example.com/user/23 (gdzie 23 to jego unikalny identyfikator). Dzięki takiemu rozwiązaniu zapewniony jest warunek bezstanowości aplikacji (nie ma ukrytego wysyłania danych aby zobaczyć dany zasób, np. http://example.com/user + cookie.id=23 do wyświetlenia zasobu użytkownika). Drugą chyba najbardziej widoczną cechą jest użycie większej ilości operacji protokołu HTTP. Zwykła aplikacja zazwyczaj używa tylko dwóch metod: POST i GET podczas gdy aplikacje napisane z wykorzystaniem REST-u mogą dodatkowo wykorzystać metody CREATE, PUT, DELETE  dzięki czemu jeden adres URI może służyć do wielu celów, gdy wywołamy adres http://example.com/user/23 metodą DELETE aplikacja powinna usunąć użytkownika o identyfikatorze 23, wywołując ten sam adres metodą PUT zaktualizujemy dane użytkownika itd. Więcej o architekturze REST możecie poczytać w sieci.

Aplikacja

Założenia aplikacji

• Aplikacja ma być bardzo uproszczona, powinna posiadać 2 główne widoki, pierwszy do tworzenia list zakupowych i wybierania ich poprzez wpisanie specjalnego identyfikatora, drugi widok powinien wyświetlać szczegóły listy wraz z produktami, oraz powinien pozwalać na dodawanie i usuwanie produktów.
• Tworzenie listy ma następować po wpisaniu w formularzu nazwy listy i wysłaniu go metodą POST do odpowiedniego kontrolera
• Otwieranie listy następować będzie poprzez wpisanie jej identyfikatora w odpowiednim formularzu i wysłanie go metodą GET do kontrolera list
• Dodawanie produktów odbywać się będzie poprzez wysłanie danych z formularza (nazwa i ilość) metodą POST do kontrolera produktów
• Kasowanie produktów odbywać się będzie poprzez wysłanie identyfikatora produktu metodą DELETE do kontrolera produktów

Konfigurowanie projektu

Na początek skonfigurujemy wszystkie zależności wymagane w projekcie przy użyciu maven-owskiego pliku pom.xml.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>shopping-list</groupId>
<artifactId>shopping-list</artifactId>
<version>0.1.0</version>
<packaging>war</packaging>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<!-- <packagingExcludes>**/web.xml</packagingExcludes> -->
<webXml>web/WEB-INF/web.xml</webXml>
</configuration>
</plugin>
</plugins>
</build>
<repositories>
<repository>
<id>morphia</id>
<url>http://morphia.googlecode.com/svn/mavenrepo/</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>aopalliance</groupId>
<artifactId>aopalliance</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>com.google.inject</groupId>
<artifactId>guice</artifactId>
<version>3.0</version>
</dependency>
<dependency>
<groupId>com.google.inject.extensions</groupId>
<artifactId>guice-servlet</artifactId>
<version>3.0</version>
</dependency>
<dependency>
<groupId>org.mongodb</groupId>
<artifactId>mongo-java-driver</artifactId>
<version>2.5.2</version>
</dependency>
<dependency>
<groupId>com.google.code.morphia</groupId>
<artifactId>morphia</artifactId>
<version>0.99</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-rest-plugin</artifactId>
<version>2.2.3.1</version>
</dependency>
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-core</artifactId>
<version>2.2.3.1</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.16</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<type>jar</type>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-convention-plugin</artifactId>
<version>2.2.3.1</version>
</dependency>
<dependency>
<groupId>com.google.inject.extensions</groupId>
<artifactId>guice-struts2</artifactId>
<version>3.0</version>
</dependency>
</dependencies>
<modules>
</modules>
</project>

Poza podstawowymi frameworkami (Guice i Struts) użyjemy również dwóch pluginów Strutsa2 które ułatwią pisanie aplikacji, oraz pozwolą zaimplementować architekturę REST, zostaną one opisane później. Aby dodać biblioteki Morphia potrzebne było skonfigurowanie dodatkowego repozytorium (jako repozytorium służy strona google code).

Naszym głównym frameworkiem będzie Struts2 który będzie odpowiadać za przekierowywanie naszych żądań do odpowiednich klas i generowanie odpowiedzi, Guice będzie pełnił rolę narzędzia do wstrzykiwania zależności (zob. Dependency Injection) dlatego też potrzebujemy plugin Guice-Struts2 który to pozwoli ładnie połączyć oba frameworki.

Jak w każdej aplikacji webowej tak i w tej potrzebujemy skonfigurowany plik web.xml. Ponieważ nasza aplikacja nie jest szczególnie skomplikowana tak i tutaj nie będzie niczego nadzwyczajnego. No może poza jedną rzeczą.

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
id="WebApp_ID" version="2.5">
<display-name>shopping-list</display-name>
<listener>
<listener-class>com.darekzon.shoppinglist.listener.GuiceStruts2PluginListener</listener-class>
</listener>

<filter>
<filter-name>struts</filter-name>
<filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>
</filter>

<filter-mapping>
<filter-name>struts</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

</web-app>

Poza skonfigurowaniem Struts-owego flitra i przekierowaniem do niego wszystkich zapytań musieliśmy utworzyć Listener który odpowiadać będzie za wstrzykiwanie zależności. Listener stworzył Bob Lee jednak nie pamiętam skąd go pobrałem (zapewne jakaś strona w Google Code lub z forum), poza skopiowaniem Listenera zainstalowałem w nim mój moduł który będzie wstrzykiwał zależności (entity manager oraz repozytorium).

public class GuiceStruts2PluginListener extends GuiceServletContextListener {

public Injector getInjector() {
return Guice.createInjector(
new Struts2GuicePluginModule(),
new ServletModule() {
@Override
protected void configureServlets() {
// Struts 2 setup
bind(StrutsPrepareAndExecuteFilter.class).in(Singleton.class);
filter("/*").through(StrutsPrepareAndExecuteFilter.class);

install(new ShoppingListModule());
}
});
}

}

Pora na konfigurację głównego frameworka, ponieważ ostatnio zniechęciłem się do XML-a użyję plików *.properties które umieszczam w głównym folderze z źródłami.
Plik struts.properties odpowiedzialny jest za konfigurację Strutsa i wygląda następująco:

struts.objectFactory = guice

# Fix exception "Cannot cast HttpHeaders to String"
struts.rest.namespace =

struts.mapper.class = rest
struts.convention.action.suffix = Controller
struts.convention.action.mapAllMatches = true
struts.convention.action.alwaysMapExecute = true

struts.convention.relative.result.types    = dispatcher
struts.convention.default.parent.package = rest-default
struts.convention.package.locators  = actions

struts.devMode = true

Na samym początku konfigurujemy fabrykę obiektów (czyli wskazujemy Strutsowi aby używał pluginu Struts2Guice o którym wspomniałem wcześniej).
Opcja struts.rest.namespace to przestrzeń nazw dla serwisów REST-owych (tak jakby kontekst pod którym będą dostępne). Ustawienie tej wartości na „nic” pozwoli uniknąć bardzo uciążliwego problemu przez którego nie można było używać HttpHeaders jako rezultatu metod (zob. błąd 3616 ), warto dodać, że wartość tą należy zostawić pustą, wstawienie „” spowoduje wyrzucanie wcześniej wspomnianych błędów.

struts.mapper.class pozwala ustalić jak żądania URL będą mapowane (co będzie wywoływane po wpisaniu adresu url), rozwinięcie tej nazwy znajdziecie w plikach konfiguracyjnych konkretnego pluginu (w tym przypadku wystarczy wejść do biblioteki struts2-rest-plugin i otworzyć plik struts-plugin.xml).Kolejne wartości ustalają jak ma działać plugin Convention, aby dowiedzieć się co oznaczają możecie przejść do odpowiedniej sekcji na stronie pluginu.

Konfiguracja bazy danych jest bardzo prosta, wystarczy podać dane dostępowe takie jak host, port, login oraz haslo, a także tzw. datastore (czyli nazwę bazy). To wszystko odbywa się w pliku database.properties którego nie trzeba przytaczać.

Jak działają pluginy Strutsa

W aplikacji mamy doczynienia z dwoma pluginami Struts2, pierwszy z nich Convention będzie mapować nasze adresy URL na pakiety i klasy co to znaczy?
Załóżmy, że mamy dwie klasy com.darekzon.application.UserController oraz com.darekzon.application.user.DetailsController. Niech nasza aplikacja będzie dostępna pod adresem http://example.com/. W takim przypadku adres http://example.com/user wywoła nam klasę UserController, natomiast adres http://example.com/user/details wywoła klasę DetailsController znajdującą się w pakiecie user.
Rest-plugin działa trochę inaczej, on do mapowania używa metod HTTP. Mając nasz kontroler UserController możemy go wywołać na 4 sposoby za każdym razem zostanie wywołana inna metoda.

 GET         - http://example.com/user  - zostanie wywołana metoda INDEX
POST       - http://example.com/user  - zostanie wywołana metoda CREATE
 GET         -  http://example.com/user/ID  - zostanie wywołana metoda SHOW
 PUT         - http://example.com/user/ID - zostanie wywołana metoda UPDATE
 DELETE - http://example.com/user/ID - zostanie wywołana metoda DELETE

Metoda PUT oraz Delete muszę mieć dodatkowy parametr ID (identyfikator obiektu) ponieważ są wykonywane na obiekcie (więc logiczne, że trzeba wskazać obiekt). Gdy do metody GET dodamy identyfikator zostanie wywołana metoda SHOW ponieważ aplikacja wie że w tym wypadku, nie chcemy listy a konkretny obiekt.

Drugi kontroler

Nie będę pokazywał jak powstał pierwszy kontroler, bo jest on na tyle prosty, że nie wymaga opisu, zabawę zaczniemy z drugim, najważniejszym kontrolerem który  odpowiadać będzie za obsługę całej listy, a zwie się ShoppingListController.
Ponieważ ShoppingListController będzie operować na danych, musimy wskazać mu klasę która będzie do tego przeznaczona, w tym przypadku jest to ShoppingListRepository a dodajemy ją do kontrolera poprzez wstrzyknięcie

ShoppingListRepository shoppingListRepository;

@Inject
publicvoid setShoppingListRepository(ShoppingListRepository pr){
this.shoppingListRepository = pr;
}

Szczegółowa implementacja tej klasy dostępna jest w źródłach.
Ważny jest również fakt, że klasa ta implementuje interfejs ModelDriven<T>, dzięki temu gdy poprosimy o dane w formacie XML nasza aplikacja będzie wiedziała jaki obiekt przetworzyć do żądanej postaci. Gdyby nie było tego interfejsu, przy prośbie o format XML dostalibyśmy przetkonwerterowaną całą klasę ShoppingListController czego chcemy uniknąć. Interfejs ten wymaga od nas zaimplementowania jednej metody „public T getModel()” zwracającej obiekt który będziemy konwertować (w razie konieczności).

Strona początkowa:

Strona początkowa aplikacji posiada dwa formularze, pierwszy otwiera listę o zadanym przez nas identyfikatorze, druga po podaniu nazwy tworzy taką listę. Widok prezentuje się następująco:

Strona początkowa

Pierwsza metoda jaką wywołujemy (czyli index wchodząc pod adres http://example.com/shopping-list/index.xhtml) wygląda następująco:

public HttpHeaders index(){
if(this.id != null && this.list==null){
returnnew DefaultHttpHeaders("notfound").withStatus(404);
}
if(this.id !=null && this.list!=null){
// BUG - even with directly setted 302 status application is returning 201 (created) status.
return new DefaultHttpHeaders("show").setLocationId(this.id).withStatus(302);
}
return new DefaultHttpHeaders("index");
}

Tak naprawdę mogłaby być ona pusta z racji, że jej jedynym zadaniem jest wyświetlenie dwóch formularzy, ale wysyłanie formularza otwierającego listę powoduje wywołanie w/w metody (a nie metody show jak mogłoby się zdawać) dzieje się tak ponieważ wysłanie formularza przenosi nas pod adres http://example.com/shopping-list/index.xhtml?id=IDENTYFIKATOR  – a tego plugin rest nie potrafi zmapować do metody SHOW. W metodziej tej sprawdzamy oczywiście, czy lista istnieje, jeśli nie, wyświetlamy komunikat (cały widok) z informacją o braku listy oraz co ważne wysyłamy status HTTP 404 (NOT FOUND).
Jeśli lista została znaleziona wysyłamy jej identyfikator oraz status 302 (FOUND) który powinien wymusić na przeglądarce automatyczne przekierowanie pod prawidłowy adres (tj. http://example.com/shopping-list/ID.xhtml)

Tworzenie listy:

Lista tworzona jest po wysłaniu formularza metodą post pod adres http://example.com/shopping-list/index.xhtml, wtedy wywoływana jest metoda create która wygląda następująco:

@Validations(requiredStrings = {@RequiredStringValidator(type = ValidatorType.FIELD, fieldName = „list.name”, message = „You must set shopping list name a value for string.”)})
public HttpHeaders create(){
String id = this.shoppingListRepository.create(this.list);
returnnew DefaultHttpHeaders(„create”).withStatus(201).setLocationId(id.toString());
}

Nad wyraz prosta (jak cała aplikacja) metoda składa się z 3 części:

1. ustawienie walidatora tak by wymagał podania nazwy listy
2. przesłanie listy (z wypełnionym polem nazwy) do repozytorium w celu zapisania w bazie
3. zwrócenie nagłówków ze statusem 201 (CREATED) oraz identyfikatorem listy w celu przejścia do strony z listą

Metodę tą możemy wywołać na 3 sposoby, poprzez wypełnienie formularza na stronie oraz wciśnięcie przycisku, poprzez wysłanie zapytania w formie XML-a (metodą CREATE) pod adres http://example.com/shopping-list.xml lub wysłanie zapytania w formie JSON (również CREATE) pod ten sam adres lecz z rozszerzeniem json.

Po wywołaniu tej metody zostajemy automatycznie przekierowani pod adres http://example.com/shopping-list/ID.xhtml który wywołuje metodę show.
Strona z listą zakupów prezentuje się jak poniżej:

Lista zakupowa

public HttpHeaders show(){
 if(this.list == null){
 returnnew DefaultHttpHeaders("notfound").withStatus(404);
 }
 returnnew DefaultHttpHeaders("show").withStatus(200);
 }

W metodzie tej sprawdzamy jedynie czy lista istnieje, jeśli nie, generujemy informację o braku listy (jak w metodzie index) oraz zwracamy status 404 (NOT FOUND), w innym przypadku wyświetlamy listę oraz zwracamy status 200 (OK).

Dodawanie produktów

Dodawanie produktów następuje poprzez wysłanie formularza z nazwą produktu oraz ilością jaką chcemy kupić metodą POST do klasy ProductController co ma insynuować tworzenie nowego Produktu gdy tak naprawdę będziemy jedynie aktualizować naszą listę. Poniżej znajduje się wynik wysłania formularza.

Dodawanie produktu do listy

Po dodaniu produktu wysyłamy status 204 (NO CONTENT) ponieważ nie chcemy wysyłać niczego, zamiast tego odświeżamy naszą stronę dzięki czemu dostajemy świeże dane. Gdybyśmy zamiast tego chcieli wysłać naszą listę i odświeżyć ją poprzez javascript musimy wysłać status 200 (OK)

Kasowanie produktów

Aby wykasować produkt z listy należy kliknąć w ikonę koszyka która pojawia się po najechaniu na nasz produkt. Po kliknięciu javascript automatycznie wyśle żądanie typu DELETE w odpowiedzi dostając status taki sam jak przy dodawaniu.

Inne formaty

Aby zobaczyć naszą listę zakupową w innym formacie wystarczy otworzyć stronę z rozszerzeniem XML:

Lista zakupowa w formacie XML

bądź JSON:

Lista zakupowa w formacie JSON

Dzięki temu możemy zintegrować naszą aplikację z aplikacjami zewnętrznymi bez zbędnego nakładu pracy.

Podobne tematy

1. Podobny tutorial: http://www.zulutown.com/blog/2009/01/28/rest-web-application-with-struts21-rest-and-convention-plugins/
2. Hypertext Transfer Protocol: http://www.w3.org/Protocols/rfc2616/rfc2616.html
3. Nieco krytycznie o REST: http://michalorman.pl/blog/2011/02/bullshit-bingo-rest-i-restful/
4. Prezentacja na temat REST: https://www.soa.edu.pl/c/document_library/get_file?uuid=46b0faf6-6743-4184-ab16-dbddfd413685&groupId=10122

Jakiś czas temu IBM wypuścił mały poradnik jak tworzyć aplikacje wielozadaniowe, co zrobić by uchronić się przed deadlock-ami, co zrobić by nie stracić wydajności naszej aplikacji.
Wszystko to napisane przystępnym językiem wraz z masą przykładowego kodu.

Kurs dostępny jest pod adrese,: http://www.ibm.com/developerworks/training/kp/j-kp-concurrency/index.html?ca=drs-

Bardzo często chcemy aby nasza aplikacja miała możliwość wysyłania maili, czy to aby wysłać mail aktywacyjny dla nowo zarejestrowanych użytkowników czy też w postaci formularza kontaktowego. Na szczęście biblioteki Java zawierają w sobie klasy dzięki którym bardzo łatwo osiągniemy nasz cel. Jeśli nie mamy własnego serwera który odpowiedzialnyby był za wysyłanie poczty możemy użyć do tego celu serwerów Google i usługi Gmail.

Aby wysyłać maile w aplikacjach javowych potrzebujemy biblioteki Javax Mail, możemy ją dodać poprzez zależności w maven-ie:

<dependency>

<groupId>javax.mail</groupId>

<artifactId>mail</artifactId>

<version>1.4.1</version>

<type>jar</type>

<scope>compile</scope>

</dependency>

lub pobierając ze strony projektu.

Po pobraniu i dołączeniu bibliotek do naszego projektu musimy skonfigurować połączenie z serwerem smtp (odpowiedzialnym za wysyłanie maili), aby to zrobić tworzymy plik konfiguracyjny.

Plik „mail.properties” zawierający ustawienia umieszczamy w folderze głównym zawierającym źródła tak aby był łatwy do znalezienia, jego zawartość powinna wyglądać następująco:

mail.smtp.host= smtp.gmail.com
mail.smtp.port= 587
mail.smtp.auth= true
mail.smtp.starttls.enable = true
mail.smtp.quitwait= false
mail.user= username
mail.password = password
mail.encoding= "utf8"
mail.debug= false

W powyższym pliku ustawiamy host, port oraz dane autoryzacyjne. Opcja mail.smtp.starttls.enable=true wymusza na aplikacji aby używała operacji StartTLS która to ustanawia szyfrowanie TLS w połączeniu sieciowym.
Opcja mail.smtp.quitwait odpowiada za rozłączanie się z serwerem, w normalnych warunkach, nasza aplikacja wysyła polecenie QUIT i czeka na potwierdzenie rozłączenia, my nie musimy czekać, więc zaraz po wysłaniu polecenia rozłączamy się od serwera.
Mając plik konfiguracyjny potrzebujemy kodu który go wczyta i utworzy sesje mailową która odpowiada za wysłanie wiadomości., robimy to wykorzystując mechanizmy Javy a dokładniej klasę Properties

Properties properties = new Properties();

try {

properties.load(this.getClass().getResourceAsStream("/mail.properties"));
} catch (IOException e) {
e.printStackTrace();
 throw new RuntimeException("Fatal error");
}

Jeśli mamy wczytane ustawienia możemy przejść do wysyłania maila. Aby to zrobić tworzymy nową sesję (połączenie z serwerem smtp) oraz wiadomość.

</span>
<pre>
Session session = Session.getInstance(properties);

MimeMessage mm = new MimeMessage(session);

try {
    mm.setFrom(new InternetAddress(properties.getProperty("ADRES_NADAWCY@example.com"),properties.get Property("NAZWA_NADAWCY")));
    mm.setRecipient(Message.RecipientType.TO, new InternetAddress("ADRES_ODBIORCY@example.com","NAZWA_ODBIORCY"));
} catch (UnsupportedEncodingException e) {
    e.printStackTrace();
}

mm.setText("WIADOMOSC");
mm.setSubject("TEMAT_MAILA");
Transport t = session.getTransport("smtp");
t.connect(this.getProperty("mail.user"),this.getProperty("mail.password"));
t.sendMessage(mm, mm.getAllRecipients());

Wszystko powinno działać od ręki, z tego co pamiętam, Gmail ma ograniczenie do 500 maili dziennie (w darmowej usłudze) o czym trzeba pamiętać, choć możliwe, że już się to zmieniło.

Jak podają chyba wszystkie zagraniczne blogi twórca Javy James Gosling opuścił firmę Google (do której przeszedł po przejęciu Sun-a przez Oracle). Jak głosza plotki pan Gosling zajął stanowisko głównego architekta oprogramowania w firmie Liquid Robotics która zajmuje się tworzeniem robotów oceanicznych.

Więcej możecie przeczytać w źródłach:

1. Infoworld - Java founder Gosling leaves Google for startup
   
2. Liquid Robotics – James Gosling joins Liquid Robotics

Jakiś czas temu pisałem o przenosinach Twittera do JVM. Tym razem prezentuję film z udziałem Raffiego Krikoriana który pracuje w Twitterze. Opowiada o tym jak przenosili się z Ruby do JVM.

Nad maszyną wirtualną javy zebrały się czarne chmury (a może raczej obłoczki). Jak się okazuje 7 wersja maszyny wirtualnej Javy (chodzi o wersję HotSpot Server wydanej zaledwie kilka dni temu) zawiera trzy niepokojące błędy, które zostały odkryte przez programistów związanych z fundacją Apache (pracującymi nad projektami Apache Solr oraz Apache Lucene).

Błędy (7070134, 7044738 i 7068051) mogą doprowadzić do awarii maszyny wirtualnej lub złych obliczeń.

Pierwszy błąd dotyczy błędnej optymalizacji pętli wykonywanej przez kompilator. Optymalizacja (włączona domyślnie) może być wyłączona przez podanie argumentu:

-XX:-UseLoopPredicate

Błąd nr. dwa dotyczy optymalizacji rozwijania pętli która spowodować może zwrócenie błędnych wyników.
W pewnych rzadkich sytuacjach, gdy kompilator wykona OSR (podmiany na stosie) dla zagnieżdżonej pętli może dojść do duplikacji która zamieni wyniki obliczeń. Aby uporać się z tym błędem trzeba dodać argument:

-XX:LoopUnrollLimit=1

Ostatni błąd również dotyczy optymalizacji pętli i dostał się do JVM wraz z nową funkcją optymalizatora.

Ludzie z Organizacji Apache radzą by do czasu naprawienia w/w błędów nie migrować do nowej wersji JVM. Oracle zapowiedziało usunięcie błędów w najbliższej łacie serwisowej.

Źródła:

1. http://lucene.apache.org/#28+July+2011+-+WARNING%3A+Index+corruption+and+crashes+in+Apache+Lucene+Core+%2F+Apache+Solr+with+Java+7
   
2. http://blog.eisele.net/2011/07/dont-use-java-7-are-you-kidding-me.html
3. http://www.infoworld.com/t/java-programming/apache-and-oracle-warn-serious-java-7-compiler-bugs-168516

Z racji, że ostatnio nie mam zbyt dużo czasu na nowe wpisy w ramach przeprosin postanowiłem zrobić akcję Google+, jeśli ktoś jeszcze nie ma jeszcze konta może zostawić swój mail (podpięty do Google Account) w komentarzu (w formie rozczytywalnej dla mnie).

Komentarze po wysłaniu zaproszenia będą kasowane.

Uwaga!

Google raz na jakiś czas zawiesza napływ nowych ludzi, więc może się to przeciągnąć w czasie.

PS. Jak już będziecie mieć konto, możecie splusować wpis ;)

PS 2. Zapraszanie zakończone, mam nadzieję, że wszyscy którzy się zgłosili dostali już konta.

Twitter to chyba największa strona napisana w języku Ruby (framework Ruby On Rails), a na pewno największa jeśli chodzi o moc obliczeniową jaką potrzebuje do codziennej pracy. Można powiedzieć, że była oczkiem w głowie programistów Ruby, jako argument, iż język jest dojrzały i bardzo dobry jeśli chodzi o poważne zastosowania. Jednak od jakiegoś czasu ktoś wyjątkowo wytrwale dłubie w tym oku, tym kimś jest nie kto inny jak sam Twitter który powoli przenosi swój kod do języków uruchamianych w JVM.

Wszystko zaczeło się jeszcze w 2010 roku kiedy to Twitter ogłosił, że programiści przepisali w języku Scala silnik kolejkowania oraz magazynowania wiadomości.
W kwietniu tego roku zmieniony został mechanizm składowania indeksów wyszukiwarki, od teraz za indeksowanie odpowiada Lucene dzięki czemu opóźnienie podczas wyszukiwania skróciło się trzykrotnie a przepustowość wzrosła dziesięciokrotnie, front-end wyszukiwarki również został zaktualizowany, od teraz zamiast Ruby On Rails wykorzystywany jest  mechanizm Blender (oparty o framework JBoss Netty).
Od kuchni Twitter do składowania danych używa bazy MySQL oraz rozproszonej bazy danych Cassandry. Do przetwarzania offline, używany jest Hadoop który ciągle zyskuje coraz większą popularność.

Powyższe zmiany w architekturze Twittera mogą świadczyć iż choć Ruby jest już językiem dojrzałym to nie nadaje się do projektów wymagających wysokiej wydajności o skalowalności (szczególnie jeśli chcemy zmniejszyć koszty działania).
Sam Twitter jest również niezłym laboratorium z którego wyników można czerpać garściami, z pewnością polecam obserwowanie dalszego rozwoju akcji.

Źródło:

1. http://www.infoq.com/articles/twitter-java-use
2. http://engineering.twitter.com