Certified Spring Professional

Certyfikat SpringSource Certified Spring Professional zdobyty! Wynik to 88%. Powiem szczerze, że wymagał sporo nauki. Egzamin składa się z 50 pytań wielokrotnego wyboru, czas to 88 minut.
Dla potomnych przygotowujących się do egzaminu polecam:

1. http://springcert.sourceforge.net/
2. Scott Selikoff's blog
3. java black belt mock exam

Oraz obowiązkowo materiały ze szkolenia Core Spring oraz dokumentacja.

Java black belt mock exam w moim odczuciu odbiega sporo od zakresu egzaminu, niemniej jednak polecam gdyż można sprawdzić stan swojej wiedzy.

Płatny test na skill guru moim zdaniem (w przeciwieństwie do innych opinii) nie przygotowuje do egzaminu - także nie polecam. Są tam pytania o moduły spoza zakresu (np. SpEL), za mało pytań o konfigurację fabryki oraz cykl życia, brak też dobrych pytań o AOP.

Co dalej? Myślę, że uzupełnię wpisy na blogu o moduły których się uczyłem a nie zdążyłem tutaj zamieścić.

Jdbc w spring

Dziś omówię dostęp do danych za pomocą JdbcTempate.
Praca z jdbc jest nużąca i nastręcza wiele problemów, stąd zapewne powstały w javie i są bardzo popularne różny ORM-y. Czemu nie piszę zatem o JPA czy hibarnate (przyjdzie i na to czas) - otóż uważam, że w pewnych sytuacjach jdbc jest idealnym wyborem w dostępie do danych. Jak to mawia mój kolega: "nie strzelajmy z armaty do muchy".
Pracując z jdbc musimy obsługiwać transakcje, zarządzać połączeniem, obsługiwać wyjątki (a cóż można zrobić jak poleci SQLException przy zamykaniu połączenia ?). Generalnie trzeba napisać mnóstwo kodu technicznego, obsługującego specyfikę jdbc, aby móc wykonać jakikolwiek zapytanie. I pewnie jest to świetne miejsce aby skorzystać z dobrodziejstw aspektów. Można, ale nie trzeba - inni (deweloperzy ze springsource) zrobili to już za nas dając JdbcTemplate.

Spring aop - różne typy metod advice

W pierwszym poście na temat spring aop wspomniałem o typach advice-ów :
Typy advice-ów :

• before - advice uruchomi się przed wykonaniem join point-a.
• afterReturning - advice uruchomi się po poprawnym wykonaniu join point-a.
• afterThrowing - advice uruchomi się po rzuceniu wyjątku z join point-a.
• after - advice uruchomi się niezależnie od tego czy metoda wykonała się bezbłędnie czy nie.
• around - advice uruchomi się po before, sami tutaj odpowiadamy za wywołanie join point-a i zwrócenie wartości.

Spring AOP - definiowanie poincut-ów cz. 2

Post ten nawiązuje do dwóch poprzednich w tematyce spring aop. Będę opierał się o ten sam projekt.
Definiując pointcut możemy uzyskać dostęp do kontekstu join point-a. Do tego kontekstu należą:

• this - oznacza rzeczywisty obiekt, na którym została wywołana metoda (proxy)
• target - oznacza obiekt zawierający join point (bean springa, którego metodę 'aspektujemy')
• argumenty wywołania metody
• adnotacje związane z metodą.

Są to informacje, które mogą się okazać użyteczne podczas implementacji kodu advice.

Spring AOP - definiowanie poincut-ów cz. 1

Post ten nawiązuje do poprzedniego posta o spring aop.
Przypomnijmy, że spring aop pozawala na aspektowanie wyłącznie metod publicznych na beanach.
Pointcut to 'wyrażenie regularne' pozwalające springowi znaleźć interesujące nas metody. Spring zaczerpnął sposób ich definiowania z AspectJ.

Ogólny szablon wygląda tak :

execution(typ_zwracany pattern_na_ścieżkę_pakietowa_do_klasy? pattern_na_nazwę_metody(pattern_na_parametry) 
pattern_na_deklarowane_wyjątki?)

gdzie oczywiście opcjonalne wartości są zaznaczone znakiem '?'.

Wstęp do Spring AOP.

W dzisiejszym wpisie wystąpi trochę anglojęzycznych zwrotów - ucząc się AOP nie próbowałem niektórych pojęć tłumaczyć i zapożyczyłem je, jeśli szanowny Czytelnik ma pomysł na tłumaczenia proszę o komentarz.

Aby zrozumieć czym jest, a może ważniejsze - po co jest AOP spójrzmy na dwa problemy występujące w systemach :

1. "Tangling" - mówi o tym, że mamy pomieszany kod biznesowy z kodem obsługującym : transakcyjność, logowanie, obsługę wyjątków itp. - jakiś kod techniczny.
2. "Scattering" - mamy podobny kod rozsiany po całym systemie - np kod obsługi transakcyjności, otwieranie sesji hibernate itp.
   

AOP mówi o tym, żeby takie kawałki kodu znaleźć, wyekstrahować do osobnego bytu i zaaplikować do kodu biznesowego. Oddzielamy kod biznesowy od kodu technicznego. Mówiąc po ludzku : z kodu biznesowego wyciągamy to, co nie jest kodem logiki biznesowej, następnie umieszczamy go w innej klasie, dalej AOP 'automagicznie' sprawia, że w czasie wykonania wyjęty przez nas kod mimo wszystko zostanie uruchomiony.