Mamy jednak do dyspozycji Mavena i jego mechanizm pluginów:

Listing 1. Konfiguracja pluginu kompilatora JR

	org.codehaus.mojo
	jasperreports-maven-plugin
	1.0-beta-2
	
		target/jasperreports/compiled
		true
		src/main/resources/jasperreports
		xml
	
	
		
			
				compile-reports
			                                                       
compile
		
	

Nas interesuje opcja sourceFileExt, która pozwala na określenie jakie rozszerzenie ma plik z szablonem raportu. Dzięki temu można użyć plików z rozszerzeniem xml, które są prawidłowo edytowane w Eclipse.

Dodaj do

Postaram się przez najbliższych kilka dni przygotować i udostępnić archetyp zawierający:

• Vaadin
• JSR-303
• JPA2
• Shiro
• Guice

Całość przetestowana za pomocą testng.

Dodaj do

W maven 3 jest trochę zmian. Jedną z bardziej bolesnych jest kompletna zmiana sposobu zarządzania profilami w ramach pliku settings.xml. W maven 2 było tak, że w tagu profile dało się upchnąć m.n. domyślną konfigurację pluginów. W maven 3 nie jest to możliwe, bo o ile jeszcze po umieszczeniu np. tagu build w definicji profilu maven strzeli tylko delikatnego focha w trakcie gry wstępnej i poinformuje nas, że ten tak jest wybitnie nie na miejscu:

Listing 1. Komunikat o niedozwolonym tagu

$ mvn clean
[WARNING]
[WARNING] Some problems were encountered while building the effective settings
[WARNING] Unrecognised tag: 'build' (position: START_TAG seen ...j7\n\t\t\t... @140:11)  @ /home/koziolek/maven3/conf/settings.xml, line 140, column 11

To już znacznie większym problemem może okazać się stosowanie takiej metody konfiguracji jako domyślnej np. na serwerze CI. W takim przypadku informacje zawarte w pliku settings.xml zostają olane, a jakaś niewinna duszyczka musi nosić koszulkę z wyznaniem winy, bo akurat to po jej commicie się posypało.

Jak sobie z tym poradzić?

W mavenie 2 mało kto korzystał z expressions do konfiguracji projektu. Zazwyczaj ograniczało się to do użycia ich w celu oznaczanie wersji Springa/Guice czy jakiegoś nietypowego ustawienia dziedziczonego przez kilka pluginów.
Ja wykorzystam je tutaj do eleganckiego zdefiniowania ustawień związanych z różnymi wersjami JVM.

Dodanie konfiguracji do settings.xml

Otwieramy odpowiedni plik settings.xml. Odpowiedni to znaczy:

• plik umieszczony w $MAVEN_HOME/conf jeżeli chcemy zastosować konfigurację do wszystkich wywołań mavena niezależnie od użytkownika.
• plik umieszczony w ~/.m2 jeżeli chcemy zastosować konfigurację tylko do konkretnego użytkownika.

W sekcji settings/profiles dodajemy:

Listing 2. konfiguracja profili

			j6

				/home/koziolek/java/bin/javac
				true
				1.6
				1.6
			
		

			j7

				/home/koziolek/java7/bin/javac
				true
				1.7
				1.7
			
		

i więcej jak mamy taką potrzebę.

Następnie w sekcji settings/activeProfiles dodajemy

Listing 3. wybór profilu domyślnego

j6

Lub jakikolwiek inny, który chcemy używać jako domyślny. Brak wskazania domyślnego profilu skutkuje uruchomieniem każdego builda z konfiguracją domyślną co oznacza m.n. użycie javy w wersji 1.5 (z dokładnością do tego jak działa flaga -target w javac, ale to innsza inszość).

Co oznaczają poszczególne flagi?

• maven.compiler.source – tak jak source w specyfikacji kompilatora.
• maven.compiler.target – tak jak target w specyfikacji kompilatora.
• maven.compiler.executable – pełna ścieżka do pliku kompilatora.
• maven.compiler.fork – najważniejsza z flag. Powoduje, że proces kompilacji jest uruchamiany jako osobny proces w systemie dzięki czemu można użyć zewnętrznego kompilatora.

Jak widać ostatnia flaga steruje całą magią konfiguracji. Jeżeli przestawimy ją na false to możemy spodziewać się różnych ciekawych efektów ubocznych. Począwszy od kompilacji projektu pod javę 5, poprzez kompilację z użyciem np. Hot-Spot zamiast JRockit, a kończąc na błędach samego kompilatora mówiących, że “sorry cie bardzo nie ta wersja javy”.

Dodaj do

Ten tutorial jest przeznaczony na n00bów.

Ważną rzeczą jest zachowanie odpowiedniej kolejności działań. Inaczej trzeba będzie niektóre z nich powtórzyć.

• Usuń z systemu mavena 2 za pomocą polecenia:

  Listing 1. Usuwanie mavena 2

  $ sudo apt-get remove maven2; sudo apt-get autoremove

• Ściągnij i rozpakuj paczkę z mavenem 3. Zakładam, że rozpakowałeś ją do ~/maven3
• Wykonaj:

  Listing 2. Konfiguracja mavena 3

  $ sudo ln -s ~/maven3/bin/mvn /usr/bin/mvn

I tak oto masz Maven 3 na pokładzie.

I oto przykład na to, że motywator w postaci 50euro działa. Ponad rok od podjęcia decyzji o przejściu na Mavena 3 w końcu to zrobiłem ;D Od dziś wszystkie wpisy na blogu będą budowane z wykorzystaniem mavena 3.

Dodaj do

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