Java Spring -- przykład problemu, jaki ostatnio rozwiązałeś(-aś)

Proszę o podanie przykładu problemu związanego konkretnie z frameworkiem Spring, na który ostatnio natrafiłeś(-aś), z ewentualnym podsumowaniem rozwiązania.

Interesuje mnie to, ponieważ temat znajomości Spring pojawia się bardzo często w rozmowach na forum, ja sam piszę oprogramowanie korzystające ze Springa.
W związku z tym, że to nie ja wymyśliłem architekturę, moja styczność z samym Springiem ogranicza się do rzeczy bardzo mocno trywialnych -- w zasadzie tylko tworzę w beans.xml kolejne definicje pól w obiektach (DI?), kolejnych parametrów konfiguracji, kolejnych odpalanych wątków.

Nigdy nie byłem świadkiem tego, by ktoś miał problem z samym Springiem, natomiast oczywiście byłem świadkiem sporej liczby problemów związanych z programowaniem i technologiami pokrewnymi.

PS Uprzedzając pytania, oczywiście googlowałem niejednokrotnie czym Spring jest i jak się ma do alternatywnych rozwiązań.

Dosyć niedawno natrafiłem na typowy problem circular reference xd Jako, że w obu komponentach wstrzykiwanie miałem przez konstruktor. Wiem, że taka sytuacja może wskazywać na zły design, ale w tej konkretnej sytuacji ciężko mi było coś innego wymyślić. Jak naprawiłem? Wybrałem jeden z tych dwóch komponentów, w którym wstrzykiwana zależność nie jest wymagana od początku istnienia, i zmieniłem wstrzykiwanie przez konstruktor na wstrzykiwanie przez setter, z dodatkową adnotacją @Lazy xd

tak, wiem, zaraz @scibi92, @jarekr000000 i @Shalom na mnie naskoczą że hurr durr, jak to przez setter, na pewno można było zrobić lepiej :D :D :D

@Pinek: Nie rozwiązałeś problemu. Cykliczna zależność dalej występuje. Naprawiłeś co najwyżej błąd rzucany przez kontener DI.

@Pinek jak to przez setter, na pewno dało się lepiej :d

A poza tym z tym Hibernate jest troche inaczej. Np. masz relacje User <-> Role, to jak załadujesz User z rolami to role nie będa tak naprawde wskazywac na usera, de facto to będzie załadowane jak jeden do wielu :)

hurr durr, jak to przez setter, na pewno można było zrobić lepiej

a w temacie:

1. Ale dziś magię rozwaliłem. P...

2. dość czesto napotykam się na walki z wątkami (ForkJoinPool) i Spring, to nie jest dobre połączenie, a najgorsze, że często długo dobrze działa.

3. Najgorsze problemy są związane z użyciem specyficznych scope - typu np. RequestScope. Człowiek siedzi przez trzy dni i się zastanawia, jak to się dzieje, że mimo zmiany jakiś parametrów, jakieś metody w środku backendu nadal magicznie dostają orginalne wartości. Ogólnie dla ludzi, którzy korzystają z RequestScope powinno być specjalne piekiełko.
   JobScope w springbatch tak samo .

4. Czasem po refaktoringu metody przestają być public.. a mają adnotacje. (Transactional, różne Security..) i wtedy te magie przestają działać (zwykle łatwo się to wyłapuje jak już się problem pojawi, ale takie syfy czasem potrafią przelecieć przez review).

5. Testowanie tego wszystkiego co wg autorów springa jest nieważnym szczegółem implementacyjnym i lecie na adnotacjach, aspektach (transakcje, security).. jest dosyć żmudne, albo raczej mało wiarygodne. na testach zwykle działa ok. Pechowo, pracowałem w firmie gdzie security nie było nieważnym szczegółem.

@jarekr000000: a tak z ciekawoci do czego stosujesz Fork and Join ze Springiem? Bo tu mnie zaskoczyłeś :P

Dzięki @jarekr000000 oraz @Pinek (kolejność wedle kalibru odpowiedzi) za przykłady.

@jarekr000000
Odn. 1. oraz 5. Ciekawy problem, dobrze wiedzieć. Ciekawa lektura także samych komentarzy. Wychodzi na to, że nie każdy lubi magii sterowania przez XMLe, magicznych pól, które wyglądają na nigdzie nie inicjalizowane, itd. itp.
Odn. 2. Zakładam, że chodzi o podnoszenie przez Springa beana, który dzieli sobie pracę wielowątkowo. Co dokładnie tam jest powodem do walki, to ciężko mi wywnioskować.
Odn. 3. Ciekawe, myślę że rozumiem, miewałem chyba-analogiczne problemy z różnymi zasięgami różnych sesji jednego "użytkownika".
Odn. 4. Dobrze wiedzieć.

Pinek, problem ciekawy, na tyle nieskomplikowany, że nawet ja rozumiem (albo mi się tak wydaje). Specjalne wyróżnienie za poziom humoru w dyskusji, uśmiałem się :)

Konkludując, trzeba mi się będzie kiedyś przebić przez jakieś bardziej zaawansowane tutoriale Springa, a nie męczyć użytkowników :)

Odn. 2. Zakładam, że chodzi o podnoszenie przez Springa beana, który dzieli sobie pracę wielowątkowo. Co dokładnie tam jest powodem do walki, to ciężko mi wywnioskować.

To że Spring korzysta z ThreadLocali w aspektach do zarzadząnia transakcjami :)