W dzisiejszym artykule:

• Aspekty i Spring
• Koncept Aspektów
• Rodzaje Advice w AOP
• Mechanizm Proxy
• Przykład użycia

Aspekty i Spring

Programowanie aspektowe (AOP) uzupełnia programowanie obiektowe (OOP), dostarczając innego sposobu myślenia o strukturze programu. Kluczową jednostką modularności programowania obiektowego jest klasa, podczas gdy w AOP jednostką modularności jest aspekt. Aspekty umożliwiają modularyzację zagadnień (takich jak zarządzanie transakcjami), które dotyczą wielu typów i obiektów.

AOP jest paradygmatem programowania, który ma na celu zwiększenie modularności. Czyni to poprzez dodawanie dodatkowych zachowań do istniejącego kodu bez modyfikowania samego kodu. Zamiast tego, możemy zadeklarować nowy kod i nowe zachowanie osobno.

Jednym z kluczowych komponentów Springa jest framework AOP. Podczas gdy kontener Spring IoC nie zależy od AOP (co oznacza, że nie musisz używać AOP, jeśli nie chcesz), AOP uzupełnia Spring IoC, aby zapewnić wydajne rozwiązania. AOP w Springu jest używant m.in. do:

• Dostarczania deklaratywnych usług – najważniejszą taką usługą jest zarządzanie transakcjami.
• Pozwala użytkownikom implementować niestandardowe aspekty, uzupełniając ich użycie OOP o AOP.

Koncept Aspektów

Aby lepiej zrozumieć działanie i odsłonić magię aspektów, trzeba się zapoznać z tym jak ten mechanizm działa. Spójrz na obrazek i przejdź do opisu definicji, aby lepiej poznać konept aspektów.

JoinPoint

Joinpoint jest punktem podczas wykonywania programu, takim jak wykonanie metody lub obsługa wyjątku. W Spring AOP, JoinPoint zawsze reprezentuje wykonanie metody.

Pointcut

Poincut jest predykatem, który pomaga dopasować poradę (Advice), która ma być zastosowana przez Aspekt w konkretnym JoinPoincie. Często kojarzymy Advice z Pointcutem i jest ona uruchamiana w dowolnym JoinPoincie dopasowanym przez ten Poincut.

Advice

Advice jest akcją podejmowaną przez aspekt w konkretnym JoinPoincie. Są różne typy porad, o czym w kolejnym punkcie. W Springu, Advice jest modelowany jako interceptor, utrzymujący łańcuch interceptorów wokół Joinpoint.

Rodzaje Advice w AOP

Spring AOP zawiera następujące rodzaje porad:

• Before advice – porada, która działa przed JoinPointem, ale która nie ma możliwości zatrzymania wykonania programu (chyba, że rzuci wyjątek).
• After returning advice – porada, którą należy uruchomić po normalnym zakończeniu JoinPointu (na przykład, jeśli metoda powróci bez rzucenia wyjątku).
• After throwing advice – porada, którą należy uruchomić, jeśli metoda zakończy działanie rzucając wyjątek.
• After (finally) advice – porada, którą należy uruchomić niezależnie od sposobu, w jaki JoinPoint wychodzi z wykonania (normalny lub zakończony wyjątkiem).
• Around advice – porada, która otacza JoinPoint, taki jak wywołanie metody. Jest to najpotężniejszy rodzaj porady. Wokół porady może wykonywać niestandardowe zachowanie przed i po wywołaniu metody. Jest ona również odpowiedzialna za wybór, czy kontynuować wykonanie do punktu złączenia (JoinPointu), czy też skrócić wykonanie zalecanej metody poprzez zwrócenie własnej wartości lub rzucenie wyjątku.

Mechanizm Proxy

Spring AOP do utworzenia proxy dla danego obiektu docelowego używa albo:

• dynamicznych proxy JDK
• albo CGLIB

Dynamiczne proxy JDK są wbudowane w JDK, podczas gdy CGLIB jest powszechną biblioteką definicji klas o otwartym kodzie źródłowym (przepakowaną do spring-core).

Jeśli obiekt docelowy, który ma być proxowany, implementuje przynajmniej jeden interfejs, używane jest dynamiczne proxy JDK.  Natomiast jeżeli obiekt docelowy nie implementuje żadnych interfejsów, tworzone jest proxy przez CGLIB.

Przykład użycia

Zaczynamy od napisania Join Pointu – czyli w przypadku springa będzie to jakaś metoda.

@Component
public class BusinessClass{
    public void validateTransaction() {
        System.out.println("...validating");
    }
}

Definijuemy Aspect, Pointcuty oraz Advice’y. Pointcuty można definiować oddzielnie a później wykorzystywać jako ’metodę’ w Advice.

@Aspect
@Component
public class LoggingAspect {

    @Pointcut("execution(* BusinessClass.validateTransaction(..))")
    public void logAfter() {
        //pointcut
    }

    @Before("execution(* BusinessClass.validateTransaction())")     //point-cut expression
    public void logBefore(JoinPoint joinPoint) {
        System.out.println("BusinessClass.logBefore() : " + joinPoint.getSignature().getName());
    }

    @AfterReturning(pointcut = "logAfter()")
    public void logujWyjscieZUslugi(JoinPoint joinPoint) {
        System.out.println("BusinessClass.afterRetuning() : " + joinPoint.getSignature().getName());
    }
}

Po wywołaniu metody, na którą Aspekt był założony wynik naszego programu jest następujący:

BusinessClass.logBefore() : validateTransaction
...validating
BusinessClass.afterRetuning() : validateTransaction

Podsumowanie

Mechanizm AOP z pewnością jest jednym z bardziej zaawansowanych technik programowania, która w pewnym momencie kariery staje się niezbędna. Aspekty pozwalają nam na wszechstronność pisania kodu. Za ich pomocą możemy bezinwazyjnie m.in. dodać logi audytu, lub transakcyjność. Jednak z doświadczeniem przychodzi pewna pokora i chciałbym ustrzec wszystkich podjaranych, że czytelność i utrzymanie kodu jest ważniejsze niż kod napisany fajnie. Z tego powodu raczej odradzam dodawanie biznes case’ów w postaci aspektów. Pamiętaj, ten kod ktoś musi później utrzymać.

Źródła:

• https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#aop
• https://howtodoinjava.com/spring-aop-tutorial/
• https://www.baeldung.com/spring-aop
• https://blog.allegro.tech/2014/12/aspects-in-spring.html

Artykuł Aspekty i Spring 👈 pochodzi z serwisu bdabek.pl.

Cześć 

Dziś zajmiemy się omówieniem poszczególnych stereotypów. Kiedyś na rozmowie rekrutacyjnej dostałem również pytanie o stereotypy i kiedy ich używać, więc o tym też wspomnę.

W dzisiejszym artykule:

• Mechanizm wstrzykiwania zależności
• Stereotypy
• Różnice pomiędzy poszczególnymi adnotacjami

Mechanizm wstrzykiwania zależności

Podczas pierwszych wydań Springa, wszystkie używane beany były deklarowane w plikach XML. Dla większych projektów, szybko stało się to trudnym zadaniem. Na szczęście ludzie od Springa dość szybko rozpoznali problem. W późniejszych wersjach, dostarczone zostało wstrzykiwanie zależności przy pomocy andotacji i/lub konfiguracji opartej na Javie. Oznacza to, że zamiast deklarowania beanów używając plików XML, możemy wstrzykiwać zależności poprzez adnotacje, które przy odpowiedniej konfiguracji zostaną automatycznie zaczytane przez Springa.

Aby włączyć automatyczną rejestrację beanów w przypadku czystego Springa, na klasie konfiguracyjnej należy dołączyć adnotację @ComponentScan. W przypadku projektu spring bootowego nie musimy niczego dodawać. Pakiety a zarazem klasy, znajdujące się pod klasą, która uruchamia naszą aplikację zostaną automatycznie zeskanowane. Jest to oczywiście zasługa adnotacji @SpringBootApplication, która pod spodem posiada @ComponentScan.

Stereotypy

Wiedząc już, że Spring umożliwia nam wstrzykiwanie zależności za pomocą adnotacji, jakich adnotacji należy używać? Adnotacje jakich możemy użyć nazywa się stereotypami, dlatego że zostały one umieszczone w pakiecie stereotype. Adnotacje te pozwolą Springowi na zarejestrowanie nowego beana, ale trzeba uważać!

Uwaga uwaga – tak naprawdę jedyną adnotacją, która jest automatycznie wykrywana przez Springa jest adnotacja @Component! W praktyce jednak wygląda to tak, że każda z adnotacji ’potomnych’ (@Controller, @Service, @Repository) dodaje adnotację @Component w swojej deklaracji. Wynikiem tego jest oczywiście to, że nasze klasy są rejestrowane jak należy.

Różnice pomiędzy poszczególnymi adnotacjami

W tym podrozdziale omówimy każdą z wcześniej wspomnianych adnotacji.

• @Component – to ogólny stereotyp dowolnego komponentu zarządzanego przez Springa. Jeżeli bean, który chcesz oznaczyć nie pasuje do żadnej innej kategorii to ta adnotacja będzie odpowiednia.
• @Repository – stereotyp dla warstw persystencji. Jedną z zalet korzystania z tej adnotacji jest to, że ma ona włączone automatyczne tłumaczenie wyjątków. Wyjątki zgłaszane w klasach z adnotacją @Repository zostaną automatycznie przetłumaczone na podklasy DataAccessExeption Springa.
• @Service – stereotyp dla warstw usług. W klasach z tą adnotacją zawarta jest zazwyczaj logika biznesowa aplikacji.
• @Controller – stereotyp dla warstw prezentacji (Spring MVC). DispatcherServlet będzie szukał adnotacji @RequestMapping w klasach, które są opatrzone adnotacjami za pomocą @Controller, ale nie za pomocą @Component. Często spotkasz się też zapewne z bardzo podobną adnotacją @RestController, która jest właściwie tym samym ale dodatkowo dokłada adnotacje @ResponseBody oraz automatycznie konwertuje odpowiedzi do formatu JSON/XML.

Podsumowanie

To wszystko jeżeli chodzi o adnotacje do wstrzykiwania zależności w Springu. Wszystkie z nich są używane do automatycznego wykrywania beanów Springowych i zasadniczo zapewniają tę samą funkcjonalność. Różnice pomiędzy poszczególnymi adnotacjami są minimalne ale istotne, np. @Controller czy @Repository. Jednak w przypadku adnotacji @Service oraz @Component, różnica polega tylko na semantyce.

Źródła:

• Difference between @Component, @Service, @Controller, and @Repository in Spring
• @Component and Further Stereotype Annotations
• What’s the difference between @Component, @Repository & @Service annotations in Spring?

Za tydzień

Nowy rok :). A co za tym idzie pierwszy post w miesiącu, a więc krótkie podsumowanie miesiąca. Myślę, że zmieni się również format wypuszczania nowych artykułów w nowym roku, ale to już więcej opiszę za tydzień.

Artykuł 🆒 Spring – Zrozumieć Adnotacje Wstrzykiwania Zależności 👌 pochodzi z serwisu bdabek.pl.

Cześć 

Spring sprawia, że programowanie w Javie jest szybsze, łatwiejsze i bezpieczniejsze dla każdego. Spring skupia się na szybkości, prostocie i produktywności, dzięki czemu stał się najpopularniejszym na świecie frameworkiem Java.
spring.io

Cytat powyżej doskonale opisuje znaczenie Springa w dzisiejszym świecie (2020). Spring jest wszędzie – niezależnie od tego, czy chodzi o streaming telewizji, samochody z dostępem do internetu, zakupy online, czy też niezliczone inne innowacyjne rozwiązania. Dzięki swojej elastyczności, ilości projektów jakie rozwija (w sposób zadowalający programistów na całym świecie) oraz społeczeństwa (community) jakie zostało wokół niego stworzone, z pewnością można stwierdzić, że Spring Framework jest częścią obecnego świata.

Należy jednak pamiętać, że nadal jest to tylko framework a rynek bywa nieprzewidywalny. Co w przyadku, kiedy okaże się, że Spring jest już przeżytkiem? Czy będziesz musiał przepisać całą aplikację od zera tylko dlatego, że pozwoliłeś się mu uwięzić?

W dzisiejszym artykule:

• Elastyczność a kontrola
• Gdzie leży granica?
• Technika obrony przed oddaniem władzy w ręce Springa

Elastyczność a kontrola

Spring Boot, czyli jeden z podprojektów springa, który drastycznie poprawia produktywność. Pozwala na postawinie aplikacji od zera za pomocą dosłownie kilku kliknięć przy pomocy Spring Initializr. W dobie, kiedy duży nacisk jako IT kładziemy na architekturę, gdzie każdy moduł ma konkretną odpowiedzialność (mikroserwisy), Spring Boot jest świetnym wyborem bo dostarcza nam przygotowany projekt, który musimy tylko odpowiednio zakodować.

Skupiam się szczególnie na projekcie Spring Boot’owym, ale sprawa zabetonowania kodu frameworkiem równomiernie dotyczy każdego innego projektu. Generalnie chodzi o komponenty, gdzie w dużej mierze polegamy na sercu Springa – IoC, AOP. Zyskujemy dzięki temu dużą elastyczność bo możemy szybko dostarczać funkcjonalności, które chce biznes, ale jednocześnie płacimy za to tym, że polegamy na mechanizmach frameworka.

Czy jest z tym jakiś problem? Dopóki wszystko działa to nie. Problem pojawia się gdy coś przestaje działać. Wtedy okazuje się, że z 10-osobowego zespołu, jedna… może dwie osoby, mniej lub więcej wiedzą co dzieje się pod spodem (dobrze jeżeli chociaż tyle osób się znajdzie) i umieją rozwiązać problem. To nie znaczy, że mamy wywalić wszystkie frameworki z naszego kodu i napisać je samemu. Efekt końcowy będzie taki sam. Osoby, które napiszą daną rzecz za jakiś czas są nieobecne – inny projekt / zmiana pracy / emerytura.

Gdzie leży granica?

Niezaprzeczalnym faktem jest, że w znacznej większości przyapadków nie będziesz przepisywać funkcjonalności, które dostarczają Ci zewnętrzni dostawcy (biblioteki / frameworki). Dobrze byłoby wiedzieć co dzieje się pod spodem danego komponentu, jakie są kompromisy jego użycią – co zyskujemy a co tracimy. Niestety, znajomość, co dzieje się pod spodem, często nie jest adekwatna. Żeby nie teoryzować już za wiele i przejść do konkretów, to moim zdaniem granice wyznacza czas.

Załóżmy, że na projekcie używasz Spring Boota i działasz w branży księgowości. Dostałeś zadanie aby dodać nową funkcjonalność obsługi subskrypcji (użytkownicy co miesiąc płacą za usługę księgowości). Dla uproszczenia przyjmimy, że taka subskrypcja może być utworzona (użytkownik dołącza do planu księgowości), wyszukiwana (np. przez adminów systemu), przedłużana oraz może nastąpić rezygnacja przez użytkownika.

Na pierwszy rzut oka, typowy CRUD, ale tak nie jest. Nie będziemy wchodzić w domenę bo to nie jest temat tego artykułu, ale pozwól, że przedstawię Ci kilka argumentów utrudniających domenę:

• co z użytkownikami, którzy są stałymi klientami (zniżki / rabaty)
• użytkownicy, którzy wykupuja plan na kilka lat z góry (zniżki / rabaty)
• różne plany subskrypcji (np. najdroższy plan posiada support dostępny 24/7)
• subskrypcje w wersji trial (14/30 dni)

Znalazłoby się jeszcze kilka(naście) innych utrudnień, ale nie do tego zmierzamy. Jak byś to zaczął opędzlowywać w springu? @RestController, @Service, @Component nad każdą z klas, później dla metod, w których może wystąpić rollback @Transactional i jazda? Po miesiącu kodowania okazuje się, że Twój kod jest i działa. Tylko problem, że jest on w 100% zależny od Springa i jego mechanizmów.

Czy jest złoty środek, który pomoże w walce o niezależność kodu?

Technika obrony przed oddaniem władzy w ręce Springa

Skoro znamy już problem i wiemy, że Spring Framework daje nam dużo benefitów ale jednocześnie częściowo uniezależnia nas od siebie jako dostawcy, to jak możemy się tego ustrzec? Mam zarówno dobrą jak i złą wiadomość. Zacznijmy od złej – nie da się tego ustrzec. Dobra natomaist jest taka, że możemy to załagodzić.

Dlaczego nie możemy się ustrzec? Używając Springa w naszych aplikacjach zapewne będziemy chcieli skorzystać z jego głównych zalet – kontenera IoC czy też mechanizmu AOP (Aspect Oriented Programming). Mechanizmy wokół kontenera IoC są odpowiedzialne za inicjalizację, konfigurowanie i składanie obiektów (beanów), a sam kontener zarządza ich cyklem życia co znacznie ułatwia programowanie. Natomiast, jeżeli chodzi o AOP – jest to mechanizm wykorzystywany chociażby przy transakcjach, logowaniu, obsłudze wyjątków czy też kwestiach bezpieczeństwa (security).

To jak załagodzić standardowe flow?

Do tego celu przyda nam się:

• umiejętność tworzenia konfiguracji i beanów samodzielnie,
• wiedza jak działa wzorzec projektowy fasada.

I tyle. Te dwie rzeczy pomogą nam częściowo uwolnić się od zależności frameworka. Lecimy z przykładem wcześniej wspomnianych subskrypcji.

Na samym początku trzeba zdefiniować fasadę, która przykrywa wszystkie istotne akcje biznesowe (utworzenie, wyszukanie, przedłużenie, rezygnację):

public class CompanySubscriptionFacade {

	private final CreateNewCompanySubscriptionService createNewCompanySubscriptionService;
	private final UnsubscriptionService unsubscribeFromSubscriptionService;
	private final CompanySubscriptionRepository companySubscriptionRepository;

	CompanySubscriptionFacade(CreateNewCompanySubscriptionService createNewCompanySubscriptionService,
							  UnsubscriptionService unsubscribeFromSubscriptionService,
							  CompanySubscriptionRepository companySubscriptionRepository) {
		this.createNewCompanySubscriptionService = createNewCompanySubscriptionService;
		this.unsubscribeFromSubscriptionService = unsubscribeFromSubscriptionService;
		this.companySubscriptionRepository = companySubscriptionRepository;
	}

	public Result createCompanySubscription(UUID subscriberId) {
		return createNewCompanySubscriptionService.create(subscriberId);
	}

	public CompanySubscription update(CompanySubscription sub) {
		return companySubscriptionRepository.save(sub);
	}

	public Result unsubscribe(SubscriberId subscriber, SubscriptionId subscription) {
		return unsubscribeFromSubscriptionService.unsub(subscriber, subscription);
	}

	public Optional<CompanySubscription> findSubscription(SubscriptionId subscriberId) {
		return companySubscriptionRepository.findBy(subscriberId);
	}
}

Jest to czysta klasa Javowa, podobnie zresztą jak CreateNewCompanySubscriptionService oraz UnsubscriptionService (z perspektywy kodu Javowego przed konfiguracją, która za chwilę nastąpi). Teraz czas na samodzielną konfigurację:

@Configuration
public class CompanySubscriptionConfiguration {

	/**
	 * wykorzystywane w testach
	 */
	public CompanySubscriptionFacade companySubscriptionFacade() {
		InMemoryCompanySubscriptionRepository companySubscriptionRepository = new InMemoryCompanySubscriptionRepository();

		return companySubscriptionFacade(
				createNewCompanySubscriptionService(companySubscriptionRepository),
				enrollToCompanySubscription(companySubscriptionRepository, new NoOpDomainEventPublisher()),
				companySubscriptionRepository);
	}

	@Bean
	CompanySubscriptionFacade companySubscriptionFacade(CreateNewCompanySubscriptionService createNewCompanySubscriptionService,
														UnsubscriptionService unsubscriptionService,
														CompanySubscriptionRepository companySubscriptionRepository) {
		return new CompanySubscriptionFacade(createNewCompanySubscriptionService, unsubscriptionService, companySubscriptionRepository);
	}

	@Bean
	CompanySubscriptionRepository companySubscriptionRepository() {
		return new InMemoryCompanySubscriptionRepository();
	}

	@Bean
	UnsubscriptionService unsubscriptionService(CompanySubscriptionRepository companySubscriptionRepository,
													  DomainEventPublisher domainEventPublisher) {
		return new UnsubscriptionService(companySubscriptionRepository, domainEventPublisher);
	}

	@Bean
	CreateNewCompanySubscriptionService createNewCompanySubscriptionService(CompanySubscriptionRepository companySubscriptionRepository) {
		return new CreateNewCompanySubscriptionService(companySubscriptionRepository);
	}
}

Klasa konfiguracyjna natomiast jest właśnie tą klasą, która odpowiada za utworzenie beanów. Sama posiada adnotację @Configuration oraz jest odpowiedzialna za prawidłowe powiązanie zależności.

Jeżeli chcesz dodać wsparcie dla transakcji / aspektów, które wykorzystują mechanizmy Springa to nie ma z tym najmniejszego problemu. Wystarczy że dodasz nowy @Aspect dla nowego aspektu, a w przypadku transakcji @Transactional na odpowiednim beanie lub jednej z metod. Posiadasz nadal pełne wsparcie mechanizmów Springa a jednocześnie nie betonujesz kodu na wymianę na inny framework. Będzie się to wiązało z przepisaniem konfiguracji (i oczywiście wsparcia dla ewentualnie napisanych aspektów / transakcji przez owy framework).

Podsumowanie

Koncept, który tu przedstawiłem jest poniekąd inspirowany podejściem jakie może być spotkane w architekturze hexagonalnej. Jeżeli chciałbyś dowiedzieć się więcej na ten temat to w źródłach zostawiam link do świetnej prezentacji Jakuba Nabrdalika z warszawskiego JUGA oraz dodatkowo takie podejście jest przedstawione w bardzo dobrym kursie DNA (tylko drogim).

Co do samego podejścia. Plusy? Sami kontrolujemy tworzenie beanów, więc doskonale wiemy, co jest tworzone i jakie są zależności. Przy klasach z większą ilością zależności szybciej dostrzegamy problemy z kodem bo sami musimy zarządzać zależnościami. Minusem natomiast jest to, że musimy wykonać więcej pracy. Jeżeli wszystkie klasy w naszym projekcie są bean’ami (najczęściej występuje to przy wykorzystaniu architektury warstwowej), to prawdopodobnie lepiej już oddać władze w ręce Springa i niech się dzieje co się ma dziać.

Źródła:

• Spring
• WJUG #211 – [PL] Modularity and hexagonal architecture in real life: Jakub Nabrdalik

Artykuł ✔️ Spring Framework – Jak Bronić Się Przed Oddaniem Kontroli Frameworkowi? ⛔️⛔️ pochodzi z serwisu bdabek.pl.

@Override
@Transactional
public void create(Task task) throws Exception {
    em.persist(task);
    // logika biznesowa która rzuca wyjątek
    throw new Exception();
}

if (txInfo.transactionAttribute != null && txInfo.transactionAttribute.rollbackOn(ex)) {
    try {
        txInfo.getTransactionManager().rollback(txInfo.getTransactionStatus());
    }
    ...
}

```
if (this.rollbackRules != null) {
    for (RollbackRuleAttribute rule : this.rollbackRules) {
        int depth = rule.getDepth(ex);
        if (depth >= 0 && depth < deepest) {
            deepest = depth;
            winner = rule;
        }
    }
}
```

public enum Propagation {
    REQUIRED(TransactionDefinition.PROPAGATION_REQUIRED),
    SUPPORTS(TransactionDefinition.PROPAGATION_SUPPORTS),
    MANDATORY(TransactionDefinition.PROPAGATION_MANDATORY),
    REQUIRES_NEW(TransactionDefinition.PROPAGATION_REQUIRES_NEW),
    NOT_SUPPORTED(TransactionDefinition.PROPAGATION_NOT_SUPPORTED),
    NEVER(TransactionDefinition.PROPAGATION_NEVER),
    NESTED(TransactionDefinition.PROPAGATION_NESTED);
    ...
}

// nie stosuj w taki sposób
@Transactional(propagation = Propagation.REQUIRED)
public void requiredExample(String user) { 
    // ... 
}

// preferowane użycie - Propagation.REQUIRED jest ustawiany domyślnie
@Transactional
public void requiredExample(String user) { 
    // ... 
}

if (isExistingTransaction()) {
    if (isValidateExistingTransaction()) {
        validateExisitingAndThrowExceptionIfNotValid();
    }
    return existing;
}
return createNewTransaction();

@Transactional(propagation = Propagation.SUPPORTS)
public void supportsExample(String user) { 
    // ... 
}

if (isExistingTransaction()) {
    if (isValidateExistingTransaction()) {
        validateExisitingAndThrowExceptionIfNotValid();
    }
    return existing;
}
return emptyTransaction;

@Transactional(propagation = Propagation.MANDATORY)
public void mandatoryExample(String user) { 
    // ... 
}

if (isExistingTransaction()) {
    if (isValidateExistingTransaction()) {
        validateExisitingAndThrowExceptionIfNotValid();
    }
    return existing;
}
throw IllegalTransactionStateException;

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void requiresNewExample(String user) { 
    // ... 
}

if (isExistingTransaction()) {
    suspend(existing);
    try {
        return createNewTransaction();
    } catch (exception) {
        resumeAfterBeginException();
        throw exception;
    }
}
return createNewTransaction();

@Transactional(propagation = Propagation.NOT_SUPPORTED)
public void notSupportedExample(String user) { 
    // ... 
}

if (isExistingTransaction()) {
    suspend(existing);
}
return continueWithBusinessLogic();

@Transactional(propagation = Propagation.NEVER)
public void neverExample(String user) { 
    // ... 
}

if (isExistingTransaction()) {
    throw IllegalTransactionStateException;
}
return emptyTransaction;

@Transactional(propagation = Propagation.NESTED)
public void nestedExample(String user) { 
    // ... 
}

org.springframework.transaction.NestedTransactionNotSupportedException: JpaDialect does not support savepoints - check your JPA provider's capabilities

Artykuł Jak działa adnotacja @Transactional w Springu pochodzi z serwisu bdabek.pl.

Cześć!

W dzisiejszym artykule:

• Opowiem Ci historię o tym jak brak osoby odpowiedzialnej zabija odpowiedzialność zespołu
• Konfiguracja logback’a w spring boocie – na co zwrócić uwagę
• Kilka tipów odnośnie logów

Historia z projektu…

Ruszył mnie mail od przełożonego, który poprosił o wysłanie konfiguracji logbacka jaka miała być używany na produkcji. Mail był wysłany pod alias całego zespołu. Ja na projekcie jestem najkrócej więc uznałem, że nie będę dobrą osobą żeby na niego odpowiadać – błąd. Zachowałem go sobie i po kilku dniach do niego wróciłem.

Nigdy nie konfigurowałem logów na – nazwijmy to – większą skale i nie miałem w tym żadnego doświadczenia. Odpaliłem plik konfiguracyjny logback.xml i czytam. Czytam ustawienia (nie było ich dużo), czytam dokumentację logbacka + jakiś szybki tutorial o ustawieniach spring boot’a + logbacka.

Po zgłębieniu wiedzy teoretycznej (na ten moment wiedziałem czego powinienem się spodziewać po logach), zajrzałem do logów serwera. Logi na które patrzyłem nie raz (przecież na co dzień pracuję z tym systemem). Wywołuję akcję, która uruchamia jakiś log i widzę zduplikowany log. Niby jeden do drugiego podobny – wiadomość ta sama, stacktrace się zgadza. W jednym składnia jest kolorowana, wygląda to schludnie. W drugim natomiast odwołanie do konkretnej klasy i metody gdzie wywołany jest log, brak kolorowanej składni (nie jestem jakimś fanem tego żeby wszystko się świeciło, ale w ten sposób o wiele przyjemniej czyta się logi) + kilka innych drobnych różnic.

I może nie robiłbym z tego żadnego dramatu i nie pisał o tym na blogu. Ale taka konfiguracja utrzymywała się przez około półtorej roku!! Żeby nie było, konfiguracja nie dotyczyła środowiska produkcyjnego, ale wszystkich innych środowisk z których na co dzień korzystamy (+ nasze lokalne).

Nachodzi mnie pytanie – dlaczego tak się stało? I znajduję dwie odpowiedzi:

1. Brak osoby odpowiedzialnej za logi w aplikacji
2. Brak kompetencji w zespole

Numer 1. Skoro nikt nie jest odpowiedzialny to dlaczego ja mam być? Po co mam poprawiać coś co jako tako działa? Takie podejście nie jest dobre! Jeżeli widzimy (a chyba przez ten cały czas ktoś musiał to zauważyć) to dlaczego nie chcemy wziąć za to odpowiedzialności? Kieruje nami strach (że nie umiemy) czy lenistwo?

Numer 2. Tutaj mój wniosek postawiłem na zasadzie – gdyby ktoś miał kompetencje i znał temat, to by to naprawił. I też nie chcę nikogo winić, że tego nie zrobił – nie umieć, rzecz ludzka. Natomiast jeżeli chcemy aby projekt(y) nad którymi pracujemy nie zmieniały się w słynne projekty legacy, to o nie dbajmy! Użyję nawet takiego ogrodowego slangu, pielęgnujmy je.

W moim przypadku są to tylko jakieś głupie logi, ale od tego się zaczyna. Dziś logi, jutro testy, które ktoś gwarantuje, że dopisze później, a za rok szukamy nowego miejsca pracy bo projekt w jakim pracujemy to bajzel! Spuentuje to tak: jak sobie pościelisz tak się wyśpisz

Ps. jeżeli czyta to ktoś z mojego projektu, to nie bierzcie tego interpersonalnie. Chciałem podkreślić, że we wszystkim co robimy – starajmy się być solidni i dbajmy o to co rozwijamy.

Konfiguracja logback’a w spring boocie

Uff…. rozpisałem się w tej pierwszej myśli. Ten i pozostały akapit będą już sekcjami technicznymi. Ale nie napiszę Ci tutaj jak od 0 postawić projekt który będzie wyświetlał logi. Chcę tylko zwrócić uwagę na pewne rzeczy, które programiści robią często przez copy-paste, de’facto nie wiedząc co robią (w efekcie czego działa to jako tako).

W kilku projektach spotkałem się z taką implementacją logback-spring.xml – umiesz powiedzieć co jest nie tak?

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/base.xml"/>
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS}:${HOSTNAME} %highlight(%-5level) %thread --- %logger{36} : %msg%n
            </pattern>
        </encoder>
    </appender>
    <root level="INFO">
        <appender-ref ref="STDOUT"/>
    </root>
</configuration>

Wiem, że to mała rzecz… ale zwróć uwagę na include. Jeżeli zajrzymy do środka to zauważymy, że dzięki jednemu include’owi dostajemy w gratisie 2 appendery. Console i file output – co prawda, ten drugi nie zadziała dopóki nie zdefiniujemy w application.properties logging.path. Btw. tutaj znajdziesz wszystko co powinieneś wiedzieć o ustawieniach logów w spring boocie.

Wracając do ustawień logów wyżej. Przy aktualnym ustawieniu nasz output będzie zduplikowany! Taki właśnie problem mieliśmy u siebie na projekcie. Nikt nie pomyślał o tym, żeby sprawdzić co dostajemy zaciągając ustawienia z base.xml. A tam właśnie dostajemy już fajnie przygotowany console appender. Warto też dodać, że używając startera spring boota (a jak używamy spring boota, to startera pewnie też), jeżeli nie będziemy majsterkować niczego przy logach to z automatu dostajemy domyślnego logback’a z konfiguracją z base.xml.

By default, if you use the “Starters”, Logback is used for logging.

Warto też dodać, że jeżeli używamy logbacka to odpowiednio nazwijmy nasz plik konfiguracyjny. Do wyboru mamy 4 opcje: logback-spring.xml, logback-spring.groovy, logback.xml, lublogback.groovy. Jednak tutaj, znów z pomocą przychodzi nam dokumentacja:

Kilka tipów odnośnie logów

Na koniec chcę każdemu devowi chcę podrzucić kilka porad, na co zwracać uwagę przy ustawieniach logback’a.

1. Na środowiskach nieprodukcyjnych ’rozluźnij’ logowanie – co mam na myśli? Większość z nas używa jakiegoś framework’a który będzie generował zapytania do bazy. Może się zdarzyć tak, że zamiast wykonać jedno zapytanie, wykonujemy ich 50 – bo złapaliśmy się na problem N+1. Nie mając odpowiednich logów, możemy się o tym nie dowiedzieć. W najlepszym przypadku spowolnimy nieco działanie systemu, w najgorszym zabijemy go wykonując miliony niepotrzebnych zapytań.
2. Jeżeli pracujesz ze spring-bootem i używasz logbacka, przygotuj profil logów dla środowiska produkcyjnego. Dzięki temu, nie będziesz zaskoczony gdy ktoś Cię o to poprosi. Pamiętaj tylko, że tutaj polityka logowania powinna być już odpowiednio zaostrzona. Do jakiego poziomu? To zależy – takiego, który nie będzie w żaden sposób inwazyjny dla aplikacji i jednocześnie będzie mógł dać Ci informację co się stało w przypadku błędów. Jeżeli podczas developmentu będziesz stosować się do punktu 1 to prawdopodobnie warn lub error dla większości środowisk będzie odpowiedni (wybadaj to wcześniej na jakimś środwisku testowym).
3. Ucz innych – jeżeli masz wiedzę w tym zakresie, to edukuj swoich współpracowników i zachęcaj żeby sami potestowali różne ustawienia. Dziel się wiedzą na projektowych sharepointach czy confluencach. To sprawi, że nowe osoby, wchodzące na projekt będą miały referencję i będą znały standardy jakich używacie w projekcie. Dzięki wiedzy ogólnej, nikt nie będzie w stanie zrobić bałaganu cichaczem i czegoś pozmieniać. Świadomość zespołu zawsze wpłynie pozytywnie na projekt.

Podsumowanie

Celem tego wpisu było zasianie motywacji. Motywacji do tego żeby dbać o to co robimy. Większość z nas pracuje dla biznesów, które czerpią z tego zyski – a jeżeli biznesowi wiedzie się dobrze to i nam będzie dobrze. Po za aspektami czysto finansowymi uważam, że to, co każdy z nas wytwarza pokazuje charakter człowieka. Są ludzie, którzy zawsze będą robili wszystko na odwal, aby było – nie potępiam (taki charakter) ale też nie szanuję. Wracając do samych logów, korzystaj z gotowych rozwiązań (np. dostarczanych przez springa), korzystaj z dokumentacji i testuj. Jeżeli coś nie działa to to popraw. Weź odpowiedzialność na siebie – opłaci się.

Za Tydzień

Weźmiemy na tapetę EntityManagera. Będzie bardzo technicznie

Artykuł Co się dzieje gdy nie ma osoby odpowiedzialnej? Historia Z Projektu pochodzi z serwisu bdabek.pl.

W styczniu tego roku (2020) do jednego z systemów jaki rozwijamy mieliśmy dodać nowy słownik który powinien być przechowywany w pamięci cache oraz dodatkowo odświeżać się gdy ktoś wgra jego nowszą wersję. Zadanie wydawało się być proste – tym bardziej, że mieliśmy bardzo podobną implementację w naszym systemie od roku…

I tu zaczyna się cała historia.

Programista, który to implementował zaufał istniejącemu kodowi i postanowił przekopiować rozwiązanie zmieniając tylko poszczególne parametry. Takie podejście pewnie by przeszło ale… na całe szczęście pojawił się tester , który sprawdził to zadanie i jak się domyślasz po tytule – coś nie zadziałało. Słownik jak najbardziej zapisywał się w cache’u (dlatego programista nie wykrył błędu sam) – problem występował w momencie gdy była wgrywana nowa wersja słownika – cache się nie aktualizował.

<Tu pojawia się rola mojej skromnej osoby – bo programista, który to implementował był niedostępny a zadanie wróciło z testów>

Tak wyglądał kod klasy odpowiedzialnej za zarządzaniem cache’em dla tego słownika

@Service
public class SlownikUprawnienDodatkowychCache  {
    
    @CachePut("UprawnieniaDodatkowe")
    public Set<Uprawnienia> getSlownikToCache() {
        return this.getSlownikUprawnieniaDodatkowe();
    }

    @Cacheable("UprawnieniaDodatkowe")
    public Set<Uprawnienia> getSlownikFromCache() {
        return this.getSlownikUprawnieniaDodatkowe();
    }

    public void aktualizujCache() {
        getSlownikToCache();
    }

    private Set<Uprawnienia> getSlownikUprawnieniaDodatkowe() {
        // jakaś kosztowna operacja
    }
}

Pierwszą myślą jaka mi przyszła do głowy było sprawdzić jak działają pozostałe słowniki – i znów jak możesz domyślać się z tytułu – odświeżanie innych słowników nie działało. Moje na tamten czas doświadczenie z cache’m w Springu było zerowe więc to od czego zacząłem były jakieś szybkie tutoriale. Po wstępnym zapoznaniu się – jak na prawdziwego developera przystało – opisałem problem w google i przeszukiwałem podobne problemy (stackoverflow :)). Nie umiałem znaleźć odpowiedzi na mój problem – choć jak się później okazało…

I to jeszcze jako najpopularniejszy problem dotyczący Spring cache. Ja jednak ze swoją pełną ignorancją sięgnąłem do dokumentacji. Dokumentacja w Springu jest napisana bardzo dobrze ale i tam odpowiedzi nie potrafiłem znaleźć – choć była – wystarczyło przeczytać na spokojnie ze zrozumieniem.

Po dniu takiego przeszukiwania i eksperymentowania postanowiłem, że zajrzę do kodu zarządzającego cach’em w Springu. Zapiąłem się debugiem w paru miejscach i ogień . Dodam jeszcze, że słowniki były ładowane przy starcie aplikacji a kod wyglądał mniejwięcej tak:

public class CacheConfig {
....
    @EventListener(ApplicationStartedEvent.class)
    public void addToCache() {
        ....
        log.info("START pobrania slownika uprawnien dodatkowych do cache");
        this.slownikUprawnienDodatkowych.getSlownikToCache();
        log.info("STOP pobrania slownika uprawnien dodatkowych do cache");
        ...
    }
}

(I tu była kolejna wksazówka, którą tak bardzo przeoczyłem. Metoda getSlownikToCache() wywoływana jest bezpośrednio z docelowego obiektu)

Po starcie aplikacji słownik ładuje się do cache – wszystko wygląda dobrze, nowe obiekty są w pamięci, gdy się do nich odwołuję przychodzą z cache’a. Wgrywam nową wersję słownika, wciskam aktualizację cache i cisza .

public class CacheConfig {
   ...
    public void aktualizacjaSlownikaUprawnienDodatkowych() {
        slownikUprawnienDodatkowych.aktualizujCache();
    }
    ...
}

Po stronie Springa nic się nie dzieje . Mechanim uaktualnienia cache się nie uruchamia. Po chwili zorientowałem się, że aktualizacja idzie przez metodę pośrednią aktualizujCache(). Na tamten moment nie wiedziałem jeszcze, że to jest przyczyną a próbowałem już wielu innych rzeczy – i prawdę mówiąc byłem nieco poirytowany. Tak czy siak zmieniłem wywołanie na coś takiego

public class CacheConfig {
....
    public void aktualizacjaSlownikaUprawnienDodatkowych() {
        slownikUprawnienDodatkowych.getSlownikToCache();
    }
....
}

Nie miałem wielkich oczekiwań, że to zadziała – choć bardzo chciałem żeby zadziałało . Uruchamiam aktualizację w debugerze i JEST! Cache się zaktualizował ! Cieszyłem się troche jak dziecko. Po czasie połączyłem wszystkie fakty i nadrobiłem braki w przeglądnietej tylko wcześniej przeze mnie dokumentacji. Teraz wiem, że da się zrobić tak aby aktualizowanie działało przez metodę pośredniczącą. Natomiast dla naszego rozwiązania i prostoty nie było takiej potrzeby. Poprawiłem kod dla pozostałych słowników i przekazałem zadanie testerowi.

Lekcje do wyciągnięcia na przyszłość:

• czytać uważniej dokumentacje / opis podobnych problemów – gdybym z uwagą przeczytał dokumentację lub wpis na stackoverflow (albo to i to), mógłbym zaoszczędzić sobie dzień pracy.
• głebiej analizować istniejący kod – tutaj problem polegał na tym, że sugerowałem się jak już to było rozwiązane. Inne słowniki też próbowały się odświeżać przez metodę pośrednią przez co całość nie działała. Gdybym skupił się na tym co działa (ładowanie do cache przy starcie aplikacji) i porównał z tym co mam – znów – mógłbym sobie zaoszczędzić czasu.
• nie ufać w 100% cudzemu kodu – chyba nie trzeba tego komentować. Ja zaufałem, że ktoś zrobił to dobrze a wcale tak nie było i koniec końców rezultat był taki, że przynajmniej nauczyłem się jak działa cache w Springu – więc dziękuje osobie która to implementowała

Artykuł Przez rok nie działało na produkcji 😲!! Czyli @Cacheable i @Cacheput w Springu 🔥🔥 pochodzi z serwisu bdabek.pl.