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

Synchroniczność i asynchroniczność

Mając pewną długą operację zazwyczaj musimy zdecydować czy ma być ona wykonana synchronicznie czy asynchronicznie. Oba podejścia są dobre. Wybór zależy zatem od konkretnego przypadku. Ogólnie jeżeli nie mamy jakiś obostrzeń to wybór metody asynchronicznej jest co do zasady odpowiedni. Metoda synchroniczna powinna zostać wybrana jeżeli w trakcie trwania danej operacji inne działania mogą wpłynąć na jej wynik. Względnie w przypadku aplikacji webowych jeżeli kolejne żądania mogą spowodować nieprawidłowe działanie aplikacji.
Przykładowo dobrym miejscem na wykonanie akcji synchronicznej jest zdalna aktualizacja sterowników routera albo definicji raportu Jasper Reports. Czyli tam gdzie nie będziemy wstanie zagwarantować iż żądanie wysłane w trakcie operacji skończy się sukcesem.

Ten sam JVM czy inny

Jest to znacznie ciekawszy problem. Generalnie wszystko zależy od tego czy nasza operacja może doprowadzić do sytuacji w której JVM nie będzie mógł kontynuować pracy. Takich przypadków jest kilka.

Brak pamięci

Coraz rzadsza przypadłość. W czasach Javy 32bitowej i limitu niecałych 2GB na proces opłacało się wyrzucić ciężkie i pamięciożerne zadania do osobnego JVM. W razie wystąpienia wyjątku główny proces był nienaruszony. Dziś brak RAM dla JVM nie jest już problemem. Jak trzeba to się instaluje. Jak mało to się odpala coherence i współdzieli RAM pomiędzy maszynami.

Przepełnienie stosu wywołań i nieskończone pętle

W ogólności sytuacje gdzie zadanie idzie w przysłowiowe maliny. W takim wypadku siłowe ubicie procesu za pomocą SIGKILL jest zdecydowanie łatwiejsze niż próby ubicia wątku na działającym serwerze.

Nadużywanie GC w czasie działania

Sytuacja w której po zakończeniu pracy uruchamiany jest GC i radośnie sprząta… minutę, dwie… albo i więcej. Czasami tak bywa. Niestety uruchomienie GC może zablokować serwer… a to boli.

Synchroniczność wywołania zewnętrznego JVM

Mówiąc po polsku oczekiwanie na zakończenie uruchomionego procesu JVM. Zasady takie jak wymieniłem wyżej. Z tą różnicą, że opłaca się to robić tylko przy małej ilości użytkowników ponieważ osoby, które wyślą żądanie w trakcie działania procesu, ale nie wiedzą o jego uruchomieniu nie powinny spotykać się zbyt często z komunikatem w stylu “przerwa konserwacyjna”.

Dodaj do

Oczywiście takie sytuacje mają miejsce zazwyczaj wtedy gdy trafiamy na jakiś kod zastany, w którym jest burdel i chcemy w miarę niskim pozbyć się operatora new.

Okazuje się, że obsłużenie takiej sytuacji w Guice jest dziecinnie proste. Na poniższym listingu przykładowa konfiguracji wykonująca wstrzyknięcie statyczne:

Listing 1. Wstrzyknięcie statycznego pola.

public class SimpleUserModule extends AbstractModule {

	@Override
	protected void configure() {
		install(new FactoryModuleBuilder().implement(SimpleUser.class,
				SimpleUser.class).build(SimpleUserFactory.class));
		requestStaticInjection(SimpleUser.class);
	}

}

Na listingu jest też konfiguracja dla Assisted Injection, ale o tym przy innej okazji. Jak widać samo wstrzyknięcie ogranicza się do wywołania dodatkowej metody. Jedyną rzeczą, o którą należy się martwić jest dostarczenie wszystkich zależności.

I na koniec mała sonda:

• ma być więcej krótkich wpisów, ale często.
• ma być więcej długich wpisów, ale rzadziej.

Dodaj do

Co stanie się jak będziemy chcieli skompilować takie coś:

Listing 1. I co?

public class App{
	public static void main(String[] args) {
		System.out.println(sum(1,2,3));
	}                                             

	public static int sum(int...numbers) {
		int sum = 0;                              

http://google.com

		for (int i = 0; i < numbers.length; i++) {
			sum += numbers[i];
		}
		return sum;
	}                                             

}

???

Dodaj do

Który listener lepszy

Oba są dobrym rozwiązaniem. Wybór powinien nastąpić w wyniku analizy polegającej na odpowiedzi na pytanie:

Kto powinien decydować o tym, że dane zdarzenie zakończyło się sukcesem albo porażką?

Jeżeli decyzję powinien podjąć klient to lepszym jest listener z listingu 1. Jeżeli to my decydujemy to oczywiście rozwiązanie z listingu 2.
Istnieją jednak dwa wyjątki. Pierwszy to duże zróżnicowanie protokołów (zdarzeń powodujących wywołanie listenera) w tym przypadku lepszym rozwiązaniem jest druga wersja listenera. Działa ona wtedy jak adapter. Jeżeli jednak protokół jest jeden i jest dobrze zdefiniowany to pierwszy z listenerów jest wystarczający. Jego użycie upraszcza nasz kod.
Drugi wyjątek to sytuacja w której nie interesuje nas treść zdarzenia, ale tylko fakt jego zaistnienia. Jest to typowa sytuacja dla listenerów o których mówił Daniel w swoim komentarzu – loggerów, ale też np. listenerów audytowych czy listenerów związanych z bezpieczeństwem.

Zagadka właściwa

Dzisiejsza zagadka jest trochę trudniejsza. Mamy do wykonania pewne długotrwale zadanie. Wiemy, że będzie ono wykonywało się bardzo długo w stosunku do oczekiwań użytkownika. Pytanie brzmi:

Poniższa lista zawiera kilka modeli wykonania zadania. Czym będziesz kierować się przy wyborze konkretnego modelu?

• Wywołanie synchroniczne EBJ albo usługi działającej w ramach tego samego procesu JVM wraz ze zmianą konfiguracji aplikacji webowej tak by nie groził błąd HTTP 408 request timeout.
• Wywołanie synchroniczne usługi działającej w ramach innego procesu JVM.
• Wywołanie asynchroniczne EJB albo usługi działającej w ramach tego samego procesu JVM.
• Wywołanie asynchroniczne usługi działającej w ramach innego procesu JVM.

Od razu mówię, ze wszystkie punkty mają sens. Twoim zadaniem jest wskazanie przykładowych sytuacji, w których zastosowanie poszczególnych rozwiązań jest najlepsze.

Dodaj do

Przykładowo tradycyjna aplikacja wykorzystująca formularze CUD (Create, Uprade, Delete) ma zazwyczaj podpięty jeden obiekt DAO, który realizuje poszczególne operacje. Co jednak gdy chcemy informować różne usługi o zmianach zachodzących w obiekcie? Chociażby zapisywać logi do celów audytowych czy statystycznych? Oczywiście można wprowadzać zmiany. Ba! Można do tego użyć programowania aspektowego i wstawiać aspekty w runtime… można… można też od początku stosować kolekcje usług i później dodawać/usuwać pojedyncze elementy.

Jednak nie o tym chciałem, choć temat ciekawy.

Mamy sobie do zaimplementowania listener dla pewnej usługi. Wywołanie usługi może zakończyć się na dwa sposoby sukcesem albo porażką (LOL odkrywcze). Teraz zagadka.

Na poniższych listingach przedstawiono dwa interfejsy listenera pewnej usługi. Pytanie brzmi, który z nich jest lepszym rozwiązaniem i w jakiej sytuacji:

Listing 1. Listener “jednometodowy”

interface ServiceListener{
    public void onEvent(Event e);
}

Klasa Event zawiera odpowiedź usługi w czystej postaci (strumień, String, prymityw).

Listing 2. Listener “wielemetodowy”

interface ServiceListener{
    public void onSuccess(Response r);

    public void onError(Error e);
}

Klasy Response i Error zawierają odpowiedź w czystej postaci, ale są wstępnie filtrowane tak by rozróżnić sukcesy i porażki.

Dodaj do

Przygotowania

Co należy mieć zanim w ogóle przejdziemy do pracy? Po pierwsze należy zarejestrować się jako deweloper do Facebooka. Następnie w zakładce “Aplikacje” tworzymy nową aplikację. Przechodzimy do jej konfiguracji i oznaczamy jako “webside” podając URL aplikacji. Posiada ona kilka ważnych elementów:

• App ID/API Key – unikalny identyfikator aplikacji.
• App Secret – “odcisk palca”, czyli tajny identyfikator.
• Site URL – adres aplikacji
• Post-Authorize Redirect URL – adres przekierowania po uzyskaniu tokena

Najważniejsze na tej liście są adresy URL. Pierwszy z nich to adres na który skieruje nas FB jeżeli wybierzemy aplikację z menu “Aplikacje” w części użytkownika. Drugi to adres, na który zostanie przekierowane żądanie po uzyskaniu tokena (zgody użyszkodnika na dostęp do profilu).

Po stronie Vaadin

Przedstawię tu kilka luźnych klas, które łączę za pomocą Guice.

Żądanie tokenu

Tu nie ma zbyt dużo filozofii no może poza fochami Vaadin

Listing 1. Przykładowy listener dla przycisku logowania

class SecuriedButtonClickListener implements ClickListener {

	private static final long serialVersionUID = 194416383513769075L;

	@Inject
	private Application myVaadinApplication;

	@Inject
	@Named("FB.appId")
	private String appId;

	@Inject
	@Named("FB.redirect")
	private String redirect;

	@Inject
	private Random random;

	@SecureAction
	public void buttonClick(ClickEvent event) {
	        myVaadinApplication.getMainWindow().addComponent(
				new Label("Thank you for clicking"));

		String target = "https://www.facebook.com/dialog/oauth?client_id="
				+ appId + "&redirect_uri=" + redirect + "&state="
				+ random.nextInt();
		myVaadinApplication.getMainWindow().open(new ExternalResource(target),
				"_top");
	}
}

Ostatnia linijka najważniejsza. Generalnie Vaadin nie pozwala na otwieranie zasobów innych niż obrazki i pdfy w ramach dyrektywy _self. To jest ten mały foch. Gdy użyjemy _top bangla. Parametry są jasne no może poza ostatnim. Jest to tekstowy identyfikator żądania, który pozwala na identyfikację konwersacji pomiędzy serwerami FB, a naszą aplikacją.

Obsługa odpowiedzi

Tu też nie ma tu dużo filozofii. Vaadin udostępnia interfejs ParameterHandler służący do obsługi parametrów żądania. Dodajemy go do aplikacji.

Listing 2. Przykładowy listener dla odpowiedzi serwera

class StandardParameterHandler implements ParameterHandler {

	public void handleParameters(Map parameters) {
		for (Map.Entry entry : parameters.entrySet()) {
			System.out.println(entry.getKey() + "="
					+ Arrays.toString(entry.getValue()));
		}
	}
}

Odpowiedzi serwera mogą być dwojakie. Pierwsza pojawia się w momencie gdy użytkownik zgodzi się na dostęp naszej strony do jego profilu. W takim wypadku parametry w odpowiedzi są dwa. Pierwszy state to nadany przez nas identyfikator. W Przypadku Vaadin jest on średnio przydatny ponieważ aplikacja zachowuje swój stan aż do wygaśnięcia sesji HTTP na serwerze zatem nawet po opuszczeniu okna aplikacji będzie ona wisiała przez pewien czas w pamięci i odpowiedź serwera zostanie poprawnie połączona z instancją. Drugi parametr nosi nazwę code i należy go traktować jako tymczasowy identyfikator użytkownika. Posłuży on wraz z App Secret do pobrania identyfikatora użytkownika służącego do pobierania danych z Open Graph.
Drugi typ odpowiedzi pojawia się w momencie gdy użytkownik odmówił współpracy. W tym przypadku adres zwrotny będzie zawierał parametry state, error, error_reason i error_description, które opisują nam co dokładnie się stało.

Podsumowanie

Przedstawiłem tu wersję minimum. W takim przypadku użytkownik został zalogowany z pomocą FB, ale nie zostały pobrane żadne informacje o jego osobie. W takim przypadku użytkownik nadal musi wprowadzić wszelkie dane takie jak nick czy avatar. Jest to bardzo wygodna metoda jeżeli chcemy użytkownikom pozwolić na identyfikację, ale nie chcemy by podawali nam swoje dane.
Należy pamiętać też o dwóch rzeczach. Pierwsza to żądanie minimum. Nie ma sensu proszenie użytkownika o udostępnianie danych jeżeli nie będziemy z nich korzystać. Druga to właściwe zabezpieczenie aplikacji. FB pozwala na identyfikację użytkownika, ale wszelkie elementy związane z zabezpieczeniem aplikacji, przyznawaniem uprawnień itp. nadal należy wykonać własnym sumptem. Logowanie z FB to tylko logowanie – username/password nic więcej.

Dodaj do

Opis problemu

Generalnie mamy sobie kilkanaście niezależnych modułów Gucie, które łączone w różny sposób tworzą naszą aplikację. Świetnym przykładem tego typu rozwiązań są wszelkie aplikacje oparte o pluginy jak chociażby CMSy czy CRMy. Rzecz w tym, że instalacja wszystkich wymaganych modułów może być kłopotliwa. Dlaczego? Skoro moduły są niezależne to problem z konfiguracją odkryjemy dopiero po starcie aplikacji w dodatku problem ten najprawdopodobniej zgłoszą użytkownicy. Objawy? Na przykład brak części usług i funkcjonalności. Oczywiście są testy, ale…

Rozwiązanie

Nazywa się Geri^W i jest moją propozycją na prosty moduł Guice. Co robi? Otóż wykorzystując mechanizm ServiceLoader wyszukuje i instaluje moduły Guice. W obecnej wersji jest to dość prymitywne rozwiązanie, które ma wiele wad, ale na pewno będę je rozwijał i zostaną one wyeliminowane.
Do pobrania z Githuba > Geri na GitHub.

Sposób użycia

Po pierwsze po stronie Guice wystarczy:

Listing 1. Użycie Geri

Guice.createInjector(new GeriModule());

Jednak by to zadziałało trzeba odpowiednio przygotować swoje moduły.

• W META-INF tworzymy katalog services
• W nim plik o nazwie com.google.inject.Module
• W pliku umieszczamy pełną, kwalifikowaną nazwę klasy implementującą interfejs com.google.inject.Module.

Moduł ma pewne ograniczenia:

• Powinien mieć konstruktor bezparametrowy.
• Może mieć konstruktor domyślny.

W przeciwnym wypadku całość posypie się z błędami z ServiceLoader.

Jeżeli chcemy ograniczyć możliwość ładowania modułów do ładowania ich z określonych ClassLoaderów to można wywołać Geri przekazując jako parametry konstruktora nasze ClassLoadery.

Dodaj do

Po co ręcznie tworzysz obiekty?

Nie są to zwykłe obiekty, ale bardzo specyficzne – interceptory. Tworzymy je w ramach metody configure z klasy AbstractModule. Musimy je stworzyć ręcznie i nasze pole manewru w tej dziedzinie jest ograniczone. Problem zaczyna się w momencie gdy:

• Interceptor ma pewne zależności, które powinny być zarządzane przez kontener IoC.
• Zależności te mają inny zasięg niż aplikacja.

By wam nie było smutno – przykładzik:

Listing 1. Interceptor sprawdzający uprawnienia

class SecuredMethodInterceptor implements MethodInterceptor {

	@Inject
	private Subject subject;

	public Object invoke(MethodInvocation invocation) throws Throwable {
		if(subject.isAuthenticated()){
			System.out.println("OK");
		}
		return invocation.proceed();
	}
}

Jeżeli zrobimy takie coś w aplikacji webowej gdzie subject ma ustawiony zakres na sesję to dostaniemy

Listing 2. Błąd konfiguracji kontenera IoC

Error in custom provider, com.google.inject.OutOfScopeException: Cannot access scoped object. Either we are not currently inside an HTTP Servlet request, or you may have forgotten to apply com.google.inject.servlet.GuiceFilter as a servlet filter for this request.

Jak temu zaradzić?

W takim wypadku należy zastosować wstrzyknięcie providera. Oczywiście problemem może być brak takowego, ale w takim przypadku należy zastosować Assisted Injection plus providera w ramach obiektu objętego danym zakresem. Sprawa skomplikowana i nie do końca przeze mnie obczajona.

Zatem prawidłowa klasa interceptora będzie wyglądać tak:

Listing 3. Interceptor sprawdzający uprawnienia v2

class SecuredMethodInterceptor implements MethodInterceptor {

	@Inject
	private Provider subjectProvider;

	public Object invoke(MethodInvocation invocation) throws Throwable {
		Subject subject = subjectProvider.get();
		if(subject.isAuthenticated()){
			System.out.println("OK");
		}
		return invocation.proceed();
	}
}

W takim wypadku wstrzyknięty provider sam zadba o odpowiedni zakres.

Dodaj do

Generalnie współczesne obfuskatory potrafią robić kilka rzeczy poza samym zaciemnianiem nazw. Te są przydatne:

• Usuwanie nieużywanego kodu.
• Usuwanie informacji dla debuggera.
• Upraszczanie niektórych wyrażeń (shriking).
• Optymalizacja kodu m.n. wykorzystania zmiennych lokalnych.

W efekcie możemy dostać kod mniejszy i trochę wydajniejszy, ale będziemy musieli za to zapłacić bardzo wysoką cenę. Jest nią możliwość utrzymania kodu. Skoro kod wyjściowy zostanie potraktowany refaktoryzacją Zmiana nazwy to w efekcie gdy otrzymany od klienta stacktrace stanie się ciekawą łamigłówką pt. “Co to za klasa się wyjebała”.
Kolejną wadą jest utrata możliwości powtórnego użycia kodu. Obfuskowany jar, który zawiera zestaw metod narzędziowych… a ty siedzisz i piszesz wszytko od nowa
Na koniec należy też dodać utratę powiązania pomiędzy kodem, a dokumentacją. Wdrożenie nowego człowieka w projekt będzie bolesne… szczególnie jak mu się trafi obfuskowany stacktrace.

Zalety? Tak są. Obfuskatorów należy używać jeżeli piszemy na platformę JME albo Java Card i mamy ograniczenia co do ilości wyprodukowanego kodu. W takim wypadku warto użyć obfuskatora. Kolejną jest użycie obfuskatora z wyłączonym modułem zmiany nazw w celu optymalizacji kodu. Zazwyczaj jest to upraszczanie wyrażeń (np. dodawania Stringów) lepsze wykorzystanie zmiennych lokalnych, usuwanie informacji dla debuggera czy martwego kodu. Czasami niewielkie zyski w tym zakresie są jak najbardziej pożądane. Przykładowo jeżeli uda nam się zmniejszyć wielkość paczki pobieranej przez klienta o 10% to dla 100MB jara wynik 10MB mniej na pobranie jest już znaczący zarówno dla naszych dysków jak i łączy.

Ale najważniejsze. Nie używajcie obfiskatorów. Najlepiej nigdy.

Dodaj do