Cezary Sanecki

Tworząc kolejne aplikacje oparte o Springa nie zastanawiamy się nad tym jak ten słynny framework działa pod spodem. Po prostu nie ma na to czasu, ponieważ trzeba dostarczać “wartość biznesową”. Dopiero kiedy jego zawiłości sprawią nam kłopot na produkcji to zaczynamy zagłębiać się w jego czeluści. [Czytaj dalej]

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]