Cezary Sanecki

Wracam po raz kolejny po dłuższej przerwie. Nie było mnie tutaj prawie 4 miesiące! Co prawda dalej byłem aktywny w Internecie, ale bardziej na LinkedIn. Przyszła jednak pora, aby reaktywować to miejsce. [Czytaj dalej]

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]