Cezary Sanecki

Spring z założenia integruje się z wybranymi elementami specyfikacji J2EE takimi jak np. @PostConstruct oraz @PreDestroy. Jednak pomimo istnienia takiej ogólnodostępnej specyfikacji spotyka się osoby, które nie chcą “zabrudzać” kodu adnotacjami wchodzącymi w jej skład. Wynika to z myślenia, że kod domeny musi być “czysty”! [Czytaj dalej]

Pewnie tworząc beany nie raz trafiłeś na sytuację, w której rozpatrywana klasa implementuje więcej niż jeden interfejs. Okazuje się, że najlepszą metodą rejestrowania takiego beana jest rejestrowanie go jako typu najbardziej specyficznego (sekcja TIP). [Czytaj dalej]

Pozostając w kontekście rejestrowania beanów wykorzystując w tym celu adnotację @Configuration. Natrafiłem ostatnio na ciekawe rozwiązanie dostępne out-of-the-box w Springu. Chodzi o opcjonalność zależności dostarczanych dla tworzonego beana. Jeśli oczekiwany w parametrze metody, oznaczonej przez adnotację @Bean, parametr nie zostanie znaleziony (taki bean nie został zarejestrowany) to niekoniecznie musi to... [Czytaj dalej]

Tworzenie beanów to odwieczna część pracy programisty, który “babra się” w ekosystemie Springa. Jednak nawet w tak rutynowej czynności można znaleźć coś ciekawego, czego niekoniecznie jest się świadomym. Przejdźmy zatem do sedna i spradźmy czym @Configuration może nas zaskoczyć. Jednak najpierw zarejestrujmy kilka beanów wykorzystując adnotację @Bean. [Czytaj dalej]

Przeglądając dokumentację Springa natrafiłem na adnotację o nazwie @AliasFor. Pamiętam, że miałem kiedyś przypadek, w którym taki mechanizm by mi się bardzo przydał. Niestety teraz nie mogę sobie przypomnieć jak on dokładnie wyglądał. Niemniej postanowiłem i tak przedstawić działanie adnotacji @AliasFor tutaj na blogu. Być może komuś się ona przyda... [Czytaj dalej]