Na początek będzie trochę o zestawianiu środowiska, czyli o rzeczach, które trzeba niestety zrobić i nie są one zbyt przyjemne dla naszej psychiki.

W moim przypadku mam za zadanie przygotować lekki i wygodny framework do testowania naszych aplikacji webowych. Ogólne założenia:

• Pozwala na testowanie wszystkich (naszych) aplikacji.
• Pozwala na pisanie testów z zachowaniem języka domeny.
• Jest stosunkowo nieskomplikowany i łatwy w użyciu.

Ostatni punkt jest umowny o oznacza mniej więcej tyle, że API nie powinno mieć więcej niż kilka klas i odpowiadać mniej więcej elementom wizualnym w UI aplikacji oraz mapować akcje użytkownika na jakieś metody czy obiekty.

Kolejna rzecz to ten nieszczęsny “język domeny”, który w tym przypadku oznacza mniej więcej tyle co:
Dla obiektów:

• Aplikacja dzieli się na ekrany.
• Ekran jest formularzem albo listą.
• Formularz zawiera pola.
• Lista zawiera rekordy.

Dla akcji:

• Do aplikacji można się zalogować i wylogować.
• Ekran można otworzyć lub wysłać.
• Pole można odczytać i można w nim pisać.
• Listę można odczytać.

Czyli jest nieźle. Można sobie na tej podstawie wybudować jakieś ogólne wyobrażenie tego co będzie zawierać ta maszynka.

Czas na naszą narzędziownię. Będzie ona oparta o gotowe rozwiązania wspierające tworzenie testów aplikacji webowych. Zatem na pokładzie witamy:

• Selenium – framework testów webowych.
• Selenium IDE for FireFox – plugin do FF.
• Firebug – kolejny plugin do FF ułatwia pracę z kodem HTML i ma m.n. obsługę xPath.
• TestNG – silnik testów w javie, będzie nam to wszystko zbierał do kupy.
• Scala – język w jakim to wszystko napiszemy.
• Eclipse Indigo – nasze IDE.
• Maven – budowanie, zarządzanie, wkurwianie to jego domena

Tu dochodzimy do głównej części dzisiejszego wpisu, czyli jak spiąć Eclipse ze Scalą (i Selenium). O ile integracja z Selenium polega w tym przypadku na podpięciu w pom.xml:

Listing 1. zależności od Selenium

	org.seleniumhq.selenium
	selenium
	LATEST
	pom

i cierpliwym poczekaniu, aż wszystko się ściągnie to ze Scalą jest kilka wrzodów.

Scala IDE

Bardzo fajne rozwiązanie dla programistów pracujących w Eclipse, którzy chcą używać Scali. Tyle tylko, że w wersji stabilnej z obsługą Scali 2.8.0 jest moim skromnym zdaniem kompletnie nieprzydatne. Wynika to z dwóch rzeczy. Po pierwsze sam kompilator Scali wymaga dość dużo RAMu i Eclipse musi mieć w opcjach wpisane co najmniej 1024m. Trzeba pogrzebać w eclipse.ini i poustawiać -Xmx oraz -Xms. Po drugie plugin wykorzystuje swój weavering, który ma tendencję deadlocków. Rozwiązaniem jest znowuż edycja ecclipse.ini:

Listing 2. workaround do deadlocków Scala IDE

 -XX:+UnlockDiagnosticVMOptions
 -XX:+UnsyncloadClass
 -Dosgi.classloader.lock=classname

tyle tylko, że jest to rozwiązanie klasy “będzie się cięło rzadziej, ale będzie”.
Rozwiązaniem pierwszego problemu jest za to wykorzystanie Scali 2.9.0RC2 i odpowiedniej wersji IDE, czyli bety 2.0.0. W celu oszczędzenia sobie ciężkiego urazu psychicznego polecam w tym przypadku instalację manualną przez rozpakowanie paczki z pluginem do dropins i olanie update site. W razie czego można się łatwo wrzodu pozbyć.

Na koniec konfiguracja pluginu scali do mavena, który pozwala na uniknięcie instalacji Scali w systemie (czasami przydatne):

Listing 3. Konfiguracja pom.xml

	org.scala-tools
	maven-scala-plugin
	LATEST
	
		
			
				compile
				testCompile
			
		
	
	
		${scala.version}
	



	org.scala-lang
	scala-library
	${scala.version}


	org.scalatest
	scalatest
	1.3

Tu mała uwaga na temat Eclipse. Pytanie jeżeli w projekcie definiujemy scala.version i mamy je też skonfigurowane w settings.xml, to które zostanie wykorzystane? Zdrowy rozsądek podpowiada, że to z pom.xml jak to ma miejsce w przypadku chociażby pluginów. No niestety zdrowy rozsądek należy odłożyć i dzięki temu odkrywamy, że zmienne w pom.xml są nadpisywane przez te z settings.xml.
Mam tu jeszcze Scala Test, czyli takiego DSLa do testów. Przyda się.

Dodaj do

vaadin-clean

Zawiera kod różnych komponentów. W przypadku uruchomienia profilu gwt udostępniona zostanie funkcjonalność związana z menu kontekstowym w zakładce “własne komponenty”. Kod z dokumentacją!

vaadin-guice

Przykładowy projekt integracyjny Vaadin i guice. Brak komentarzy.

vaadin-scala

Durnostojka demonstrująca, że da się użyć scali. Brak komentarzy.

Dodaj do

Mały wkurw… bo nie zrobiłem backupa, ale w sumie nie ma o co, bo mam starą wersję gdzieś na backup-dysku.

Wywaliłem wszystko do cna zachowując tylko konfigurację – plik settings.xml. Rozpakowałem na świeżo i działa.

Dodaj do

Przygotowania i konfiguracja środowiska

Konfiguracja środowiska będzie przebiegać w kilku krokach. Ważną rzeczą jest by dodanie funkcjonalności ICEPush nastąpiło w momencie gdy będzie to już naprawdę niezbędne. Wynika to z konieczności każdorazowego kompilowania kodu za pomocą kompilatora GWT. To powoduje, że proces wydłuża się i to na tyle, że można spokojnie pójść na kawę. Jeżeli jednak chcecie dodać ICEPush już na obecnym etapie to warto zastosować pewien trik, który za chwilę omówię.

Pierwszym krokiem w konfiguracji środowiska jest stworzenie pakietu org.icepush.gwt i umieszczenie w nim pliku ICEpush.gwt.xml.

Listing 1. ICEpush.gwt.xml

Następnie musimy stworzyć pakiet pl.koziolekweb.vaadin.guice.widgetset zawierający plik MyAppWidgetSet.gwt.xml.

Listing 2. MyAppWidgetSet.gwt.xml

Na tym kończy się pierwszy standardowy etap konfiguracji. Drugi etap to edycja pliku pom.xml w celu dodania zależności zarówno do ICEPush jak i pluginów kompilatora GWT oraz managera widgetsetów Vaadin.

Listing 3. pom.xml – pluginy

	org.codehaus.mojo
	gwt-maven-plugin
	2.1.0-1
	
		${project.build.directory}/${project.build.finalName}/VAADIN/widgetsets
		-Xmx512M -Xss1024k
		test
		${project.build.directory}/${project.build.finalName}
		true                                                                                 
8080
		false
	
	
		
			
				resources
				compile
			
		
	


	com.vaadin
	vaadin-maven-plugin
	1.0.1
	
		
			
			
			
				update-widgetset
			
		
	

Listing 4. pom.xml – zależności ICEPush

	org.vaadin.addons
	icepush
	0.2.1


	org.icepush
	icepush
	2.0


	org.icepush
	icepush-gwt
	2.0


	com.google.gwt
	gwt-user
	2.1.1
	provided

Z taką konfiguracją możemy już działać z ICEPush w zwykłej aplikacji Vaadin. Należy co prawda dodać jeszcze odpowiedni serwlet do naszego web.xml, ale o tym na stronie dodatku.

Czas na dodanie konfiguracji Guice. Jest to kolejny przyjemny etap prac konfiguracyjnych. Tu sprawa zaczyna się jednak komplikować, bo i ile konfiguracja w pliku pom.xml

Listing 5. pom.xml – zależności Guice

	com.google.inject
	guice
	2.0


	com.google.inject.extensions
	guice-servlet
	2.0


	javax.servlet
	servlet-api
	2.5

to dalej zaczynają się drobne schody.
Po pierwsze Guice przejmuje zarządzanie serwletami od kontenera. To oznacza usunięcie z web.xml mapowania serwletów i zastąpienie ich konfiguracją filtra z Guice.

Listing 6. web.xml – konfiguracja Guice

	Vaadin-Guice-ICEPush application
	
		Vaadin production mode
productionMode
false
	

	
		guiceFilter
		com.google.inject.servlet.GuiceFilter
	
	
		guiceFilter
		/*
	

pl.koziolekweb.vaadin.guice.servlet.VaadinGuiceConfiguration
	

Następnie należy samodzielnie zaimplementować listener, który utworzy nam injector Guice:

Listing 7. Implementacja listenera Guice

package pl.koziolekweb.vaadin.guice.servlet;

import com.google.inject.Guice;
import com.google.inject.Injector;
import com.google.inject.servlet.GuiceServletContextListener;

public class VaadinGuiceConfiguration extends GuiceServletContextListener {

	@Override
	protected Injector getInjector() {
		return Guice.createInjector(new MyServletModule());
	}

}

Na koniec trzeba utworzyć moduł Guice:

Listing 8. Implementacja modułu Guice

package pl.koziolekweb.vaadin.guice.servlet;

import java.util.HashMap;
import java.util.Map;

import pl.koziolekweb.vaadin.guice.ApplicationRoot;
import pl.koziolekweb.vaadin.guice.modules.books.model.dao.BookDao;
import pl.koziolekweb.vaadin.guice.modules.books.model.dao.SimpleBookDao;
import pl.koziolekweb.vaadin.guice.modules.books.presenter.ListBookPresenter;
import pl.koziolekweb.vaadin.guice.modules.books.presenter.ListBookPresenterImpl;
import pl.koziolekweb.vaadin.guice.modules.books.view.ListBookView;
import pl.koziolekweb.vaadin.guice.modules.books.view.ListBookViewImpl;

import com.google.inject.servlet.ServletModule;
import com.google.inject.servlet.ServletScopes;
import com.vaadin.Application;

public class MyServletModule extends ServletModule {

	@Override
	protected void configureServlets() {
		Map params = new HashMap();

		serve("/*").with(GuiceApplicationServlet.class, params);

		bind(Application.class).to(ApplicationRoot.class).in(ServletScopes.SESSION);

		bind(ListBookView.class).to(ListBookViewImpl.class);
		bind(BookDao.class).to(SimpleBookDao.class);
		bind(ListBookPresenter.class).to(ListBookPresenterImpl.class);

	}
}

Na tym etapie należy chwilę się zatrzymać i zastanowić co tu się dzieje. W momencie nadejścia żądania uruchamiany jest filtr guice, który wyszukuje sobie istniejące injectory zawierające ServletModule i w zależności co mu skonfigurujemy w ramach takiego modułu oraz w zależności od ścieżki z żądania zostanie odpalony odpowiedni serwlet. Injectory są trzymane w ramach kontekstu aplikacji, a dodaje je tam implementacja GuiceServletContextListener.

No właśnie tu dochodzimy do najciekawszego elementu czyli spinania Guice z ICEPush. Jeżeli chcemy korzystać z samego Guice w Vaadin to tworzymy własny serwlet rozszerzający AbstractApplicationServlet i tyle.

Listing 9. Implementacja AbstractApplicationServlet dla Guice

package pl.koziolekweb.vaadin.guice.servlet;

import java.io.IOException;

import com.google.inject.Inject;
import com.google.inject.Provider;
import com.google.inject.Singleton;

import com.vaadin.Application;
import com.vaadin.terminal.gwt.server.AbstractApplicationServlet;

@SuppressWarnings("serial")
@Singleton
public class GuiceApplicationServlet extends AbstractApplicationServlet {

	private final Provider applicationProvider;

	@Inject
	public GuiceApplicationServlet(Provider applicationProvider) {
		this.applicationProvider = applicationProvider;
	}

	@Override
	protected Class getApplicationClass() throws ClassNotFoundException {
		return Application.class;
	}

	@Override
	protected Application getNewApplication(HttpServletRequest request) throws ServletException {
		return applicationProvider.get();
	}
}

Jednak jeżeli chcemy dodać obsługę ICEPush to musimy jakość ją włączyć do naszego serwletu. Metoda najprostsza i jednocześnie nie najlepsza to skopiowanie zawartości oryginalnego serwletu do naszego serwletu Guice. Inaczej się niestety nie da. Zatem po zmianach nasz serwlet będzie wyglądał tak:

Listing 10. Implementacja AbstractApplicationServlet dla Guice z ICEPush

package pl.koziolekweb.vaadin.guice.servlet;

import java.io.IOException;

import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.icepush.servlet.MainServlet;
import org.vaadin.artur.icepush.ICEPush;
import org.vaadin.artur.icepush.JavascriptProvider;

import com.google.inject.Inject;
import com.google.inject.Provider;
import com.google.inject.Singleton;

import com.vaadin.Application;
import com.vaadin.terminal.gwt.server.AbstractApplicationServlet;

@SuppressWarnings("serial")
@Singleton
public class GuiceApplicationServlet extends AbstractApplicationServlet {

	private final Provider applicationProvider;

	private MainServlet ICEPushServlet;

	private JavascriptProvider javascriptProvider;

	@Inject
	public GuiceApplicationServlet(Provider applicationProvider) {
		this.applicationProvider = applicationProvider;
	}

	@Override
	public void destroy() {
		super.destroy();
		ICEPushServlet.shutdown();
	}

	@Override
	public void init(ServletConfig servletConfig) throws ServletException {
		try {
			super.init(servletConfig);
		} catch (ServletException e) {
			if (e.getMessage().equals(
					"Application not specified in servlet parameters")) {
				// Ignore if application is not specified to allow the same
				// servlet to be used for only push in portals
			} else {
				throw e;
			}
		}
		ICEPushServlet = new MainServlet(servletConfig.getServletContext());

		try {
			javascriptProvider = new JavascriptProvider(getServletContext().getContextPath());
			ICEPush.setCodeJavascriptLocation(javascriptProvider.getCodeLocation());
		} catch (IOException e) {
			throw new ServletException("Error initializing JavascriptProvider",e);
		}
	}

	@Override
	protected Class getApplicationClass()
			throws ClassNotFoundException {
		return Application.class;
	}

	@Override
	protected Application getNewApplication(HttpServletRequest request)
			throws ServletException {
		return applicationProvider.get();
	}

	@Override
	protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		String pathInfo = request.getPathInfo();
		if (pathInfo != null
				&& pathInfo.equals("/" + javascriptProvider.getCodeName())) {
			// Serve icepush.js
			serveIcePushCode(request, response);
			return;
		}

		if (request.getRequestURI().endsWith(".icepush")) {
			// Push request
			try {
				ICEPushServlet.service(request, response);
			} catch (Exception e) {
				throw new ServletException(e);
			}
		} else {
			// Vaadin request
			super.service(request, response);
		}
	}

	private void serveIcePushCode(HttpServletRequest request, HttpServletResponse response) throws IOException {
		String icepushJavscript = javascriptProvider.getJavaScript();
		response.setHeader("Content-Type", "text/javascript");
		response.getOutputStream().write(icepushJavscript.getBytes());
	}
}

Użycie ICEPush oraz sztuczki i kruczki

Jeżeli koniecznie potrzebujesz używać w kodzie ICEPush, ale nie chesz mieć na karku kompilatora GWT można zrobić mały bypass. Po co? Czasami jest tak, że po zakodowaniu modułu ciężko jest dokonywac jakiś zmian. Łatwo za to jest zmienić konfigurację. Co też i zrobimy.
Na początek przygotujemy sobie mały interfejsik, który posłuży nam jako adapter do usługi comet.

Listing 11. Interfejs CometService

package pl.koziolekweb.vaadin.guice;

import com.vaadin.ui.ComponentContainer;

public interface CometService {

	public void addToContainer(ComponentContainer componentContainer);

	public void push();

}

O ile znaczenie metody push() jest oczywiste, to metoda addToContainer może być trochę tajemnicza. Otoż by móc używać ICEPush należy dodać go do okna aplikacji. My odwrócimy ten schemat dzięki czemu będziemy mieć kontrolę nad tym co dodajemy do aplikacji. Jest to szczególnie wygodne jeżeli chcemy dodać pseudo usługę, bo wtedy można umieścić na stronie info, że ICEPush jest, ale go nie ma.
Zaimplementujmy zatem nasz mock serwis:

Listing 12. Klasa FakeCometService

package pl.koziolekweb.vaadin.guice;

import com.vaadin.ui.ComponentContainer;
import com.vaadin.ui.Label;

public class FakeCometService implements CometService {

	public void addToContainer(ComponentContainer componentContainer) {
		componentContainer.addComponent(new Label("Fake CometService in use"));
	}

	public void push() {
		System.out.println("call push");
	}
}

Pamiętaj by przenieść konfigurację kompilatora GWT do osobnego profilu mavena. Inaczej i tak będziesz pijał kilka kaw ekstra w oczekiwaniu na zakończenie kompilacji.
Oczywiście przyda się też i właściwa implementacja:

Listing 13. Klasa ICEPushCometService

package pl.koziolekweb.vaadin.guice;

import org.vaadin.artur.icepush.ICEPush;

import com.vaadin.ui.ComponentContainer;

public class IcePushCometService implements CometService {

	private ICEPush icePush;

	public IcePushCometService() {
		icePush = new ICEPush();
	}

	public void addToContainer(ComponentContainer componentContainer) {
		componentContainer.addComponent(icePush);
	}

	public void push() {
		icePush.push();
	}

}

Użycie jest bardzo proste. Przykładowa konfiguracja modułu:

Listing 13. MyServletModule

package pl.koziolekweb.vaadin.guice.servlet;

import java.util.HashMap;
import java.util.Map;

import pl.koziolekweb.vaadin.guice.ApplicationRoot;
import pl.koziolekweb.vaadin.guice.CometService;
import pl.koziolekweb.vaadin.guice.IcePushCometService;
import pl.koziolekweb.vaadin.guice.modules.books.model.dao.BookDao;
import pl.koziolekweb.vaadin.guice.modules.books.model.dao.SimpleBookDao;
import pl.koziolekweb.vaadin.guice.modules.books.presenter.ListBookPresenter;
import pl.koziolekweb.vaadin.guice.modules.books.presenter.ListBookPresenterImpl;
import pl.koziolekweb.vaadin.guice.modules.books.view.ListBookView;
import pl.koziolekweb.vaadin.guice.modules.books.view.ListBookViewImpl;

import com.google.inject.servlet.ServletModule;
import com.google.inject.servlet.ServletScopes;
import com.vaadin.Application;

public class MyServletModule extends ServletModule {

	@Override
	protected void configureServlets() {
		Map params = new HashMap();
		params.put("widgetset",	"pl.koziolekweb.vaadin.guice.widgetset.MyAppWidgetSet");
		serve("/*").with(GuiceApplicationServlet.class, params);

		bind(Application.class).to(ApplicationRoot.class).in(
				ServletScopes.SESSION);

		//bind(CometService.class).to(FakeCometService.class);
		bind(CometService.class).to(IcePushCometService.class).in(ServletScopes.SESSION);
		bind(ListBookView.class).to(ListBookViewImpl.class);
		bind(BookDao.class).to(SimpleBookDao.class);
		bind(ListBookPresenter.class).to(ListBookPresenterImpl.class);

	}
}

Trzeba tylko dodać parametr z nazwą naszego widgetseta do konfiguracji serwletu. Zakres sesyjny dla rzeczywistego serwisu uchroni nas przed zapchaniem łącza w przypadku kilku aktualizacji występujących na raz.

Rozwinięcia twórcze

Mam kilka pomysłów na twórcze rozwinięcie tego rozwiązania. Przede wszystkim można dodać kolejki by serwis pobierał nowe informacje z kolejki i w przypadku dużego natłoku wywołań metody push nie zaspamował łącza. Po drugie integracja z GWTCanvas i tworzenie wykresów w czasie rzeczywistym. Po trzecie moja wersja JBisona, która będzie śledzić http różnych serwerów.

Dodaj do

W tym rozdziale omawiam instalację Vaadin jako samodzielnego jara, archetypu Maven oraz jako pluginu dla Eclipse i NetBeans.

V jak Vaadin rozdział 1 pre alpha 1

Całość jest hostowana na http://www.scribd.com/

Dodaj do

Przygotowania

W pierwszej kolejności instalujemy sobie serwer poczty. Ja wybrałem postfixa.

Listing 1. instalacja Postfixa

$ sudo apt-get install postfix
Czytanie list pakietów... Gotowe
Budowanie drzewa zależności
Odczyt informacji o stanie... Gotowe
Sugerowane pakiety:
  procmail postfix-mysql postfix-pgsql postfix-ldap postfix-pcre sasl2-bin resolvconf postfix-cdb
Zostaną zainstalowane następujące NOWE pakiety:
  postfix
0 aktualizowanych, 1 nowo instalowanych, 0 usuwanych i 0 nieaktualizowanych.
Konieczne pobranie 1321kB archiwów.
Po tej operacji zostanie dodatkowo użyte 3273kB miejsca na dysku.
Pob: 1 http://pl.archive.ubuntu.com/ubuntu/ lucid/main postfix 2.7.0-1 [1321kB]
Pobrano 1321kB w 1s (901kB/s)
Prekonfiguracja pakietów ...
Zaznaczenie poprzednio niezaznaczonego pakietu postfix.
(Odczytywanie bazy danych ... 347594 plików i katalogów obecnie zainstalowanych.)
Rozpakowanie postfix (z .../postfix_2.7.0-1_i386.deb) ...
Przetwarzanie wyzwalaczy dla ureadahead...
ureadahead will be reprofiled on next reboot
Przetwarzanie wyzwalaczy dla ufw...
Przetwarzanie wyzwalaczy dla man-db...
Konfigurowanie postfix (2.7.0-1) ...
Dodawanie grupy `postfix' (GID 131)...
Gotowe.
Dodawanie użytkownika systemowego `postfix' (UID 126)...
Dodawanie nowego użytkownika `postfix' (UID 126) w grupie `postfix'...
Nie utworzono katalogu domowego `/var/spool/postfix'.
Creating /etc/postfix/dynamicmaps.cf
Adding tcp map entry to /etc/postfix/dynamicmaps.cf
Dodawanie grupy `postdrop' (GID 132)...
Gotowe.
setting myhostname: koziolek-desktop
setting alias maps
setting alias database
mailname is not a fully qualified domain name.  Not changing /etc/mailname.
setting destinations: koziolek-desktop, localhost.localdomain, , localhost
setting relayhost:
setting mynetworks: 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
setting mailbox_size_limit: 0
setting recipient_delimiter: +
setting inet_interfaces: all
/etc/aliases does not exist, creating it.
WARNING: /etc/aliases exists, but does not have a root alias.

Postfix is now set up with a default configuration.  If you need to make
changes, edit
/etc/postfix/main.cf (and others) as needed.  To view Postfix configuration
values, see postconf(1).

After modifying main.cf, be sure to run '/etc/init.d/postfix reload'.

Running newaliases
 * Stopping Postfix Mail Transport Agent postfix                                                                                                      [ OK ]
 * Starting Postfix Mail Transport Agent postfix                                                                                                      [ OK ] 

Przetwarzanie wyzwalaczy dla libc-bin...
ldconfig deferred processing now taking place

I tyle. W trakcie instalacji zostaniemy poproszeni o podanie nazwy domeny, ale serwer posłuży nam tylko jako punkt zaczepienia do sieci i domena nie jest istotna.
Następnie tworzymy za pomocą mavena projekt java:

Listing 2. pom.xml

	4.0.0

	pl.koziolekweb.tutorial
	mail-hacking
	1.0-SNAPSHOT
jar

	mail-hacking
	http://maven.apache.org

UTF-8
	
	


				org.apache.maven.plugins
				maven-compiler-plugin
				
					1.6
					1.6
				
			

				org.apache.maven.plugins
				maven-surefire-plugin
				2.6
				
					
						src/test/resources/testng.xml
					
				
			

				org.apache.maven.plugins
				maven-eclipse-plugin
				2.8
				
					true
					true
					./
				
				
					
						eclipse
clean
						
							clean
							eclipse
						
					
				
			
		
	
	
		
			org.testng
			testng
			LATEST
			test
		
		
			org.mockito
			mockito-all
			1.8.1
			test
		
		
			javax.mail
			mail
			1.4
		
	

jako zależność dodajemy javax.mail i podpinamy do Eclipse.

Programowanie

Teoria

W uproszczeniu każda wiadomość email składa się z nagłówków i treści – ciała. Treść wiadomo zawiera treść. Znacznie interesujące są dla nas nagłówki. Zawierają one informacje kontrolne i sterujące takie jak nadawca, odbiorca, odbiorcy, listy CC i BCC, załączniki, ale też nagłówek Sender, który informuje o tym kto technicznie nadał wiadomość (zawiera informacje o użytkowniku serwera poczty) oraz Reply-To, który wskazuje do kogo będzie wysyłana odpowiedź.

Socialhaking

Kevin Mitnick esencję przedstawionej tu metody zawarł w tytule swojej książki “Sztuka podstępu. Łamałem ludzi, nie hasła”. Cała sztuka opiera się o pewne zachowania użytkownika. W zasadzie o jedno… czy naciskają “odpowiedz” patrzysz do kogo idzie odpowiedź i czy adres email zgadza się z adresem nadawcy? Coś czuję, że od dziś zaczniesz hehehe….

Praktyka

Do “chakierowania” użyję prostego programu napisanego w javie z wykorzystaniem Java Mail API.

Listing 3. Nasze super narzędzie…

package pl.koziolekweb.tutorial;

import java.util.Properties;

import javax.mail.Message;
import javax.mail.MessagingException;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.AddressException;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;

public class App {
	public static void main(String[] args) throws AddressException,
			MessagingException {
		String from = "Jaś Kowalski ";
		String to = "jełop@mójBank.pl";
		String replyTo = "devil@evil.hell";
		Properties props = System.getProperties();
		Session session = Session.getDefaultInstance(props, null);
		MimeMessage message = new MimeMessage(session);
		message.setFrom(new InternetAddress(from));
		message.addRecipient(Message.RecipientType.TO, new InternetAddress(to));
		message.addHeader("Reply-To", replyTo);
		message.addHeader("Content-Type", " text/plain; charset=UTF-8");
		message.setSubject("Pytanie");
		message.setText("Czy wykonano już przelew?");
		Transport.send(message);
	}
}

sprawdź samemu zmieniając adres TO na swojego maila.

Co ciekawe wiele klientów email nie sprawdza nagłówków i trzeba samodzielnie sprawdzić czy to gdzie wysyłamy zgodne jest z tym skąd dostajemy…

Schemat ataku

Schemat ataku jest tu bajecznie prosty. Atakujący wysyła maila z “lewymi” nagłówkami w którym pyta o duperelę. Warto by była to rzeczywista duperela np. czy wysłano już zamówioną kartę… Następnie w ramach konwersacji mailowej pytamy się czy osoba z obsługi nie była by tak miła i nie pomogła wykonać jeszcze jedną drobną operację… zmianę adresu korespondencyjnego… prawda, że duperela. Następnie zmuszamy ofiarę do zablokowania karty i zgłoszenia zapotrzebowania na nową… zgadnijcie gdzie trafi karta… Wraz z PINem w osobnym liście…
Oczywiście musimy trafić na bankiera idiotę, ale nie jest to trudne…

Schematy obrony

Podpis cyfrowy

Prosty i stosunkowo tani sposób obrony. Niekwalifikowany podpis można wyrobić sobie samemu. Bankowi przesyłamy klucz publiczny, a wiadomości podpisujemy z wykorzystaniem klucza prywatnego. Podpis kwalifikowany jest droższy, ale ma tą dodatkową zaletę, że można go wykorzystać jeszcze w kilku innych celach oraz, że daje możliwość wysyłania wiadomości z dowolnego komputera wyposażonego w czytnik kart chipowych (w teorii).

Weryfikacja nagłówków

Po stronie banku serwer poczty sprawdza czy nagłówek From i Reply-To są takie same. Metoda dobra o tyle, że klient nie musi nic robić. Wadą jest jej stosunkowo łatwe ominięcie poprzez błędy serwerów pocztowych.

Wewnętrzny system email

Postfix, ale też i inne serwery pozwalają na konfigurację w ten sposób, że cały ruch będzie odbywał się wewnątrz danej instancji serwera. Klient wykorzystuje wtedy specjalne bankowe konto mailowe. Metoda całkiem dobra, ale równie dobrze można wykorzystać jakiś wewnętrzny system wiadomości.

Dodaj do

Listing 1. Wyłączenie przeszukiwania workspace

	org.apache.maven.plugins  

	maven-eclipse-plugin

	2.8                       

	                              

		true  

		true

		./                

	                             

	                                 

		                              

			eclipse                     
clean

			                              

				clean               

				eclipse             

			                             

		                             

	                                

Wystarczy wskazać jako korzeń workspace bieżący katalog.

Dodaj do

Jedną z rzeczy, które wkurzają w Springu jest konieczność pisania kilometrowych plików XML nawet wtedy gdy wiadomo, że dana funkcjonalność jest zazwyczaj dobrze zdefiniowana i jednolita w całym systemie. Wtedy aż prosi się o dodanie jej poprzez adnotację i to najlepiej taką, która jasno mówi z jakim rodzajem usługi mamy do czynienia. Przykładem takiej usługi jest logowanie.

Większość programistów do usranej śmierci pisze w klasach wymagających logowania coś w stylu:

Listing 1. tworzenie loggera

private Logger log = LoggerFactory.getLogger(MyClass.class);

Nawet jeżeli używamy springa to zazwyczaj konfiguracja loggera jest opisana za pomocą wpisu properties w definicji beana. O ile prościej jest zrobić tak:

Listing 2. tworzenie loggera za pomocą adnotacji

@LogService
private Logger log

No to lecim…

Własny procesor adnotacji

Na początek zdefiniujmy sobie adnotację:

Listing 3. Adnotacja usługi dziennika zdarzeń

package pl.koziolekweb.loggerservice;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
@Documented
public @interface LogService {

	public static enum LoggerType {
		log4j, sfl4j, commonsLogger, javaSeLogging;
	}

	LoggerType loggerType() default LoggerType.javaSeLogging;

}

Wewnętrzny typ enum reprezentuje najpopularniejsze loggery na rynku. Domyślnie ustawiłem typ tak by korzystać z loggera JSE.
Oczywiście jeżeli jakiś debil poda typ różny od typu pola to jego problem

Testy

Jako, że Spring wręcz prosi by korzystać z TDD to i oto mamy zestaw testów:

Listing 4. Testy, testy i jeszcze raz testy…

package pl.koziolekweb.loggerservice;

import static org.testng.Assert.assertNotNull;
import static org.testng.Assert.fail;

import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;

public class LogServicePostProcessorTest {

	private LogServicePostProcessor logServicePostProcessor;

	@BeforeMethod
	protected void setUp() throws Exception {
		logServicePostProcessor = new LogServicePostProcessor();
	}

	@AfterMethod
	protected void tearDown() throws Exception {
		logServicePostProcessor = null;
	}

	@Test
	public void testPostProcessBeforeInitialization() {
		testJSE();
		testSfl4J();
		testCommons();
		testLog4j();
	}

	@Test(expectedExceptions = { IllegalArgumentException.class })
	public void testPostProcessBeforeInitializationWrongAnnotationType() {
		BadLogBean badLogBean = new BadLogBean();
		logServicePostProcessor.postProcessBeforeInitialization(badLogBean, "");
		fail("IllegalArgumentException should be threw");
	}

	@Test
	public void testLog4j() {
		Log4jLogBean log4jBean = new Log4jLogBean();
		logServicePostProcessor.postProcessBeforeInitialization(log4jBean, "");
		assertNotNull(log4jBean.getLogger());
	}

	@Test
	public void testCommons() {
		CommonsLogBean commonsBean = new CommonsLogBean();
		logServicePostProcessor.postProcessBeforeInitialization(commonsBean, "");
		assertNotNull(commonsBean.getLogger());

	}

	@Test
	public void testJSE() {
		JSELogBean jseBean = new JSELogBean();
		logServicePostProcessor.postProcessBeforeInitialization(jseBean, "");
		assertNotNull(jseBean.getLogger());
	}

	@Test
	public void testSfl4J() {
		Sfl4jLogBean sfl4jLogBean = new Sfl4jLogBean();
		logServicePostProcessor.postProcessBeforeInitialization(sfl4jLogBean, "");
		assertNotNull(sfl4jLogBean.getLogger());
	}

}

Metoda “uwspólniająca” testy to tylko taki mały helper dla pluginu moreUnit. Wiąże on test z metodą po nazwie, a nie wywołaniu co zmusza do robienia tego typu udziwnień.

Implementacja właściwa

Teraz czas na właściwą implementację klasy LogServicePostProcessor:

Listing 5. LogServicePostProcessor, czyli nasz procesorek

package pl.koziolekweb.loggerservice;

import java.lang.reflect.Field;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.BeanPostProcessor;
import org.springframework.util.ReflectionUtils;
import org.springframework.util.ReflectionUtils.FieldCallback;

import pl.koziolekweb.loggerservice.LogService.LoggerType;

public class LogServicePostProcessor implements BeanPostProcessor {

	public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
		return bean;
	}

	public Object postProcessBeforeInitialization(final Object bean, String beanName) throws BeansException {
		ReflectionUtils.doWithFields(bean.getClass(), new FieldCallback() {
			public void doWith(Field field) throws IllegalArgumentException, IllegalAccessException {
				LogService logServiceAnnotation = field.getAnnotation(LogService.class);
				if (logServiceAnnotation != null) {
					LoggerType loggerType = logServiceAnnotation.loggerType();
					switch (loggerType) {
					case javaSeLogging:
						setJavaSeLoggerService(bean, field);
						break;
					case log4j:
						setLog4jService(bean, field);
						break;
					case sfl4j:
						setSfl4jService(bean, field);
						break;
					case commonsLogger:
						setCommonsLoggerService(bean, field);
						break;
					default:
						setByType(bean, field);
						break;
					}
				}
			}

		});
		return bean;
	}

	private void setByType(Object bean, Field field) throws IllegalAccessException {
		Class type = field.getType();
		if (type.equals(Log.class))
			setCommonsLoggerService(bean, field);
		if (type.equals(java.util.logging.Logger.class))
			setJavaSeLoggerService(bean, field);
		if (type.equals(org.apache.log4j.Logger.class))
			setLog4jService(bean, field);
		if (type.equals(Logger.class))
			setSfl4jService(bean, field);
	}

	private void setCommonsLoggerService(final Object bean, Field field) throws IllegalAccessException {
		Log log = LogFactory.getLog(bean.getClass());
		setLogger(bean, field, log);
	}

	private void setJavaSeLoggerService(final Object bean, Field field) throws IllegalAccessException {
		java.util.logging.Logger log = java.util.logging.Logger.getLogger(bean.getClass().getName());
		setLogger(bean, field, log);
	}

	private void setLog4jService(final Object bean, Field field) throws IllegalAccessException {
		org.apache.log4j.Logger log = org.apache.log4j.Logger.getLogger(bean.getClass());
		setLogger(bean, field, log);
	}

	private void setLogger(final Object bean, Field field, Object log) throws IllegalAccessException {
		boolean orginalAccessFlag = field.isAccessible();
		if (!orginalAccessFlag) {
			field.setAccessible(true);
		}
		field.set(bean, log);
		field.setAccessible(orginalAccessFlag);
	}

	private void setSfl4jService(final Object bean, Field field) throws IllegalAccessException {
		Logger log = LoggerFactory.getLogger(bean.getClass());
		setLogger(bean, field, log);
	}

}

Jak widać implementacja ma konstrukcję zbliżoną do konstrukcji cepa. Kilka ifów plus obsługa debilizmów i własnych rozszerzeń typów przez użyszkodnika. Takie państwo w państwie Przydatne jeżeli komuś zamarzy się dodawanie nowych typów loggerów.

Użycie w pliku xml

By użyć tego rozwiązania w pliku XML springa wystarczy dodać wpis:

Listing 6. Użycie w konfiguracji Springa

Nawet ID nie trzeba podawać.

Podsumowanie i informacje o dostępie

Projekt jest hostowany na Google Code.
Licencja GPLv3. Sorry Winnetou inaczej nie będzie.
Budowany za pomocą Maven2.
To wszystko powinno działać do końca tego tygodnia, bo już ciężkiej kurwicy dostaję z pluginem SVN do Eclipse.
Wszystkie informacje oraz przykłady użycia, jak ktoś nie umie czytać testów będą na stronie projektu.

Dodaj do

• Przygotowanie pom.xml
• Dodatkowa konfiguracja Vaadin
• Podstawowa konfiguracja Springa i JPA
• Wygenerowanie klienta WS za pomocą Axis
• Posprzątanie wygenerowanych klas i ich konfiguracja jako beanów Springa

Kroki są podane w najwygodniejszej, moim skromnym zdaniem, kolejności. Najlepiej wykonywać je na raz (w ramach jednej sesji kodowania), ponieważ brak któregokolwiek, w przypadku naszej aplikacji, będzie powodował dość nieprzyjemny fail.
Zaczynamy…

Przygotowanie pom.xml

Z linii poleceń generujemy projekt Vaadin. Następnie dodajemy niezbędne zależności do Sprina, JPA2, Hibernate, bazy danych (postgres) oraz dodatkowo wykorzystywany w tym konkretnym miejscu ICEPush. Komponent Vaadin pozwalający na wykonywanie żądań typu push z serwera do przeglądarki (tzw. Comet). To ostatnie rozwiązanie wymaga pobrania komponentu z ICEPush-gwt ze strony icepush.org. Całość na licencji MPL no i trzeba się rejestrować. Jeżeli chcemy korzystać z tego komponentu należy dodatkowo skonfigurować Vaadin.

Dodatkowa konfiguracja Vaadin

Komponent ICEPush wymaga dwóch rzeczy. Po pierwsze należy wymienić klasę servletu obsługującego naszą aplikację. Nowa postać pliku web.xml:

Listing 1. web.xml skonfigurowany dla ICEPush

		Vaadin Application Servlet
		org.vaadin.artur.icepush.ICEPushServlet
		
			Vaadin application class to start
application
pl.koziolekweb.vaadin.codecompiler.MyVaadinApplication
		
		
widgetset
pl.koziolekweb.vaadin.codecompiler.widgetset.MyAppWidgetSet
		
		1
	

Piękne to nie jest, ale działa. Kolejnym krokiem jest stworzenie pliku MyAppWidgetSet.gwt.xml w wybranym pakiecie. Którym dokładnie? Wszystko jedno, bo to tylko sprawa organizacyjna. Plik ten powinien wyglądać w następujący sposób:

Listing 2. MyAppWidgetSet.gwt.xml skonfigurowany dla ICEPush

Ostatni wpis należy usunąć gdy chcemy budować aplikację produkcyjnie. Przy testowaniu lokalnym znacznie przyspiesza pracę.

Czyli podsumowując te dwa etapy. Mamy projekt Vaadin z dodatkowymi modułami, które go pom.xml wygląda tak:

Listing 3. pom.xml skonfigurowany dla projektu

	4.0.0
	pl.koziolekweb.vaadin.codecompiler
	code-compiler
war
	0.1
	Vaadin Web Application

UTF-8
		3.0.3.RELEASE
	

	


				org.apache.maven.plugins
				maven-compiler-plugin
				
					1.6
					1.6
				
			

				org.apache.maven.plugins
				maven-surefire-plugin
				2.6
				
					
						src/test/testng.xml
					
				
			

				org.apache.maven.plugins
				maven-eclipse-plugin
				2.8
				
					true
					true
				
				
					
						eclipse
clean
						
							clean
							eclipse
						
					
				
			

				org.mortbay.jetty
				maven-jetty-plugin
				6.1.24
				
					9966
					code-compiler
					0
					
						/code-compiler
						
							src/main/webapp,${project.build.directory}/${project.build.finalName}
						
					
				
			

				org.codehaus.mojo
				gwt-maven-plugin
				1.3-SNAPSHOT
				
					${project.build.directory}/${project.build.finalName}/VAADIN/widgetsets
					-Xmx512M -Xss1024k
					clean
					${project.build.directory}/${project.build.finalName}
					true
8080
					false
				
				
					
						
							resources
							compile
						
					
				
			

				com.vaadin
				vaadin-maven-plugin
				1.0.1
				
					
						
							update-widgetset
						
					
				
			
		
	

	
		
			vaadin-snapshots
			http://oss.sonatype.org/content/repositories/vaadin-snapshots/
			
				false
			
			
				true
			
		
		
			vaadin-addons
			http://maven.vaadin.com/vaadin-addons
		
		
			jboss
			http://repository.jboss.org/maven2
		
	

	
		
		
			com.vaadin
			vaadin
			6.4.7
		
		
			org.vaadin.addons
			icepush
			0.2.0
		
		
			org.icepush
			icepush
			2.0
		
		
			org.icepush
			icepush-gwt
			2.0
		
		
			com.google.gwt
			gwt-user
			2.0.4
			provided
		

		
		
			axis
			axis
			1.4
		

		
		
			org.hibernate.java-persistence
			jpa-api
			2.0-cr-1
		
		
			org.hibernate
			hibernate-entitymanager
			3.5.0-Beta-2
		
		
			postgresql
			postgresql
			8.4-702.jdbc4
		

		
		
			org.springframework
			spring-core
			${spring.version}
		
		
			org.springframework
			spring-web
			${spring.version}
		
		
			org.springframework
			spring-beans
			${spring.version}
		
		
			org.springframework
			spring-context
			${spring.version}
		
		
			org.springframework
			spring-aop
			${spring.version}
		
		
			org.springframework
			spring-context-support
			${spring.version}
		
		
			org.springframework
			spring-tx
			${spring.version}
		
		
			org.springframework
			spring-orm
			${spring.version}
		
		
			org.springframework
			spring-jdbc
			${spring.version}
		
		
			org.springframework
			spring-test
			${spring.version}
		

		
			javax.servlet
			servlet-api
			2.5
		

		
			org.slf4j
			slf4j-api
			1.4.2
		
		
			org.slf4j
			slf4j-log4j12
			1.4.2
		

		
		
			org.testng
			testng
			LATEST
			test
		
		
			org.mockito
			mockito-all
			1.8.1
			test
		
	

Podstawowa konfiguracja Springa i JPA

Przejdźmy teraz do konfiguracji Springa i JPA. Na konfigurację składa się kilka plików. Jednak zanim je pokażę to muszę omówić to jak wygląda classpath w obecnym stanie aplikacji. Otóż jeżeli chcemy prawidłowo skonfigurować aplikację do współpracy z JPA to będziemy musieli stworzyć plik META-INF/persistance.xml. Problem tkwi w tym, gdzie jest prawidłowe położenie katalogu META-INF. Okazuje się, że w musi się on znajdować w ${project.base}/src/main/webapp/WEB-INF/classes/META-INF/. Można to obejść odpowiednio konfigurując resource-plugin. Ja jednak nie miałem na to siły.
Oto lista plików konfiguracyjnych:

• persistance.xml – konfiguracja JPA.
• service.properties – konfiguracje różne, których nie chcemy w pliku springa.
• spring.xml – konfiguracja springa.
• log4j.xml – konfiguracja log4j.

Jadąc po kolei.

persistance.xml

W wersji dla Postgresa. Pamiętajcie by mieć już założoną bazę danyc.

Listing 4. persistance.xml wersja postgresowa

Później do tego pliku będziemy dopisywać mapowane klasy. To już jednak twój problem by o tym pamiętać

service.properties

Czyli różne ustawienia, które warto mieć gdzieś pod ręką, ale nie koniecznie w pliku springowym.

Listing 5. service.properties

ideone.user=******
ideone.pass=******

Mam tu na razie tylko informacje o danych dostępowych do serwisu.

spring.xml

Konfiguracja springa. Najważniejszy element układanki. Też będzie rósł, ale będę wam mówił co dodałem

Listing 6. spring.xml

Na razie tyle wystarczy.

log4j.xml

Wbrew pozorom istotny plik. Jak coś nie bangla i nie sypie błędami to właśnie tu można poszukać przyczyny.

Listing 7. log4j.xml wersja postgresowa

Wygenerowanie klienta WS za pomocą Axis

Zrób to w Eclipse. W zasadzie tyle. Adres pliku wsdl znajdziesz w dokumentacji lub jak sam go tworzysz to wiesz gdzie jest.

Posprzątanie wygenerowanych klas i ich konfiguracja jako beanów Springa

Wygenerowane klasy mają zapewne brzytkie nazwy i jeszcze gorsze pakiety. Generalnie usuwamy podkreślenia z nazw, a całosć przenosimy do jakiegoś rozsądnego pakietu. Kolejnym etapem jest dopisanie konfiguracji do pliku spring.xml:

Listing 8. Konfiguracja API Ideone w springu

Oczywiście pytanie jak wygląda ServiceUser:

Listing 8. ServiceUser dane do logowania

package pl.koziolekweb.vaadin.codecompiler.data;

public class ServiceUser {

	public final String user;
	public final String pass;

	public ServiceUser(String user, String pass) {
		super();
		this.user = user;
		this.pass = pass;
	}

	public String getUser() {
		return user;
	}

	public String getPass() {
		return pass;
	}

}

No i mamy konfigurację…

Optymalizacja za pomocą Springa

Drugą rzeczą jaką się dziś zajmiemy jest “optymalizacja” aplikacji Vaadin za pomocą Springa. Przez optymalizację rozumiem tu ograniczenie ilości pamięci zużywanej przez Vaadin.
Na początek musimy przypomnieć sobie informacje o tym jak Spring tworzy instancje poszczególnych ziaren. Jedyne co nas interesuje to informacja, że domyślnie każde ziarno jest singletonem. Ta informacja jest ważna z kilku powodów. Po pierwsze musimy pamiętać, że spring nie wie, że pracuje w trybie web oraz, że warto by było gdyby niektóre komponenty dostarczał świeże. Samodzielnie musimy zagwarantować takie zachowanie poprzez odpowiednią konfigurację. Po drugie skoro wiemy, że komponenty GUI powinny być dostarczane na świeżo musimy zobaczyć, które z nich mogą być współdzielone pomiędzy użytkownikami. Zazwyczaj są to komponenty statyczne, których treść nie jest edytowana i nie zależy od stanu sesji użytkownika. Na przykład stopka. Po trzecie należy wiedzieć i pamiętać, że Vaadin przechowuje stan ekranu po stronie serwera! Zatem jeżeli 100 użytkowników otworzy 100 okien (sesji http) to otrzyma np. 100 obiektów stopki. Niby nic, ale dużo. Po stronie serwera będą leżeć identyczne, niemodyfikowalne obiekty w dużych ilościach. Zatem można spokojnie zamienić je na jeden współedzielony obiekt. Spring zadba by nie stała mu się krzywda np. usunięcie z pamięci.

Przykład będzie w kolejnej części w której połączymy się z WS, wywołamy testową metodę oraz zaczniemy budować UI.

Dodaj do

Przy okazji jednego z poprzednich wpisów pojawiło się pytanie o wydajność Vaadin. Jest to dość istotne jeżeli przyjmiemy, że nasza aplikacja powinna być skalowalna. Kwestia wydajności tego typu rozwiązań jest zawsze dyskusyjna. Bo czymże jest wydajność? Jak ją mierzyć w odniesieniu do aplikacji dostarczających web-GUI? Niewątpliwie najważniejszym czynnikiem jest szybkość odpowiedzi na żądania. Na tym polu Vaadin sprawuje się bardzo dobrze, ale by tak było muszą zostać spełnione pewne warunki.

Vaadin to interfejs

Po pierwsze aplikacja jest tylko dostawcą GUI. Logika biznesowa ogranicza się do minimalnego minimum. Aplikacja ma być tylko interfejsem pozwalającym na wywoływanie metod interfejsów biznesowych. Najlepiej w postaci całkowicie asynchronicznego dostępu do komponentów. To uzyskujemy dzięki zastosowaniu technologii AJAX.
Po drugie sposób dostępu do interfejsów biznesowych powinien być łatwo “przepinalny”. Oznacza to, że aplikacja będzie wykorzystywać różne usługi i komponenty biznesowe pobierając informacje o nich za pomocą jakiegoś interfejsu fabrykującego. Interfejs taki powinien pozwalać na przesłonięcie rzeczywistej implementacji nie tylko na poziomie “jak to jest zrobione”, ale też na poziomie “w czym to jest zrobione” inaczej mówiąc jeżeli zgłaszam się po jakiś interfejs to mnie nie obchodzi czy uzyskam komponent EJB, bean Springa czy endpoint webservice. W praktyce jedyną rzeczą jaka powinna mnie obchodzić powinno być tylko podanie prawidłowej nazwy komponentu. I to nazwy domenowej, a nie wskazania na źródło! Przykład takiej implementacji pokazałem w poście o integracji Vaadin ze Springiem.
Po trzecie należy pamiętać o ograniczeniach wynikających z samej natury aplikacji webowych. Nie należy płakać, że przy 50requestach na minutę zawierających ciężkie zapytania np. raporty z bazy danych nasz serwer padł. Jeżeli jest to serwer typu 111 – 1 rdzeń, 1GB ram, 1połączenie do bazy to nie należy się dziwić. Pod tym względem należy zachowywać czujność rewolucyjną i w razie czego dostawiać kolejne maszyny. Niestety era aplikacji biznesowych, które mieściły się w 64kb RAM odeszła do lamusa.

Zatem jeżeli chcemy pisać wydajne aplikacje w Vaadin należy pamiętać, że jest to narzędzie do budowy interfejsu graficznego i takim powinno pozostać. Należy też wziąć pod uwagę, że web-GUI zazwyczaj nie jest najcięższym obliczeniowo elementem, ale dobrze napisane można pominąć w rozważaniach o pojedynczym scenariuszu. Zazwyczaj problemy leżą gdzieś w logice biznesowej, a ta jest wyprowadzona z GUI.

Niezbędne przygotowania dla naszej aplikacji

Chcąc stworzyć aplikację – klienta WebService musimy poczynić pewne przygotowania. Po pierwsze musimy mieć WS. Ja wykorzystam API udostępnione przez Ideone.com, które to pozwala na zdalną kompilację kodu w jednym z wielu dostępnych języków. Całość śmiga pod kontrolą Gentoo, zatem mamy do dyspozycji wszystkie kompilatory dostępne w tej dystrybucji. Jeżeli zatem chcesz przerabiać dokładnie mój przykład zarejestruj się na Ideone.com(bezpłatnie) i skonfiguruj sobie dostęp do API.
Po drugie musicie uzbroić się w cierpliwość. Będę chciał pokazać kompletny projekt, a to jest dużo kodu. Będę korzystał ze Springa3, JPA 2 i Hibernate 3.5. Platformą budującą będzie Maven 3. Całość uruchomię na serwerze Jetty.

Do miłego

Dodaj do