@budyn: Tyle że ten operator do niczego się nie nadaje, jeżeli nie będzie się wpuszczało nulli do swojego kodu. Jest obejściem problemu, którego w pierwszej kolejności nie powinno w ogóle być.

@Koryntiusz: Tyle że w tym przypadku to wina Reactora, a nie samego programowania reaktywnego.

PS Możesz się przyjrzeć operacji Hooks.onOperatorDebug() w Reactorze.

@bagi1: #mickiewicz

@JSkrzetuski: Da się. Należy przestać używać Javy. A tak na serio: nie znam dokładnie API strumieniowego w Javie, ale przy ładnym formatowaniu (tzn. każde wywołanie metody w osobnej linii) taki zapis jest zupełnie normalny w świecie programowania funkcyjnego. Możesz nawet pójść o krok dalej i fragmenty tego one-linera powydzielać do sensownie nazwanych pól i to na nich operować.

@sprayy: Już sam fakt że dwa mikroserwisy korzystają z tej samej bazy danych sugeruje że być może problem jest już na poziomie designu. Tak przynajmniej wynika ze schematu. To z kolei sugeruje że być może w rzeczywistości nie macie mikroserwisów, a rozproszony monolit. Nie pisze tego żeby się czepiać, tylko być może rzuci to Wam inne światło na ten problem.

Co do rozwiązania, to moim zdaniem opcje są dwie:
a)Pokaż całość

@bananowynick: IMO złoty środek to taki, w którym zespół składa się zarówno z backendowców jak i frontendowców, w proporcjach takich jakich wymaga tego projekt (np. 4x backend + 2x front). Mówię oczywiście o większych i wymagających projektach, gdzie przydaje się mieć ludzi wyspecjalizowanych w konkretnych tematach. Oczywiście frontendu jako backendowiec ciężko uniknąć, ale dobrze jeżeli jest go zdecydowanie mniej niż 50% o których mówisz. No i oczywiście z dystansem podchodziłbymPokaż całość

@interface: Transakcje zarządzane adnotacjami to raczysko #niepopularnaopinia.

@coola: Niestety wujek Bob w świecie programowania funkcyjnego nie jest żadnym autorytetem, a wręcz przeciwnie - uważa się że nie rozumie na czym FP polega i że artykuły przez niego publikowane są nieprawdziwe i szkodliwe. Artykuł który podlinkowałeś był bardzo mocno hejtowany, choćby dlatego że niektóre z prezentowanych tam stwierdzeń dosyć jednoznacznie obnażają ignorancję wujaszka.

@Jakr: Szukaj pod kątem "shade pluginu" (np. Maven Shade Plugin). Będziesz miał wówczas w pliku JAR (lub ogolnie na sciezce klas) obie te konfliktujące ze sobą zależności, z tym że będą występowały pod różnymi pakietami.

@Jakr: Dawno nie używałem tego pluginu (dzięki Bogu), ale dobra wiadomość jest taka że powinieneś być w stanie osiągnąć to co potrzebujesz. Jak coś to wołaj.

@ThePawel: Ale czy to źle? Jest przecież resilience4j, który ma przyjemniejsze API i większe możliwości.

@Kresse: Bardzo dobra odpowiedź, ale dorzucę swoję trzy grosze:
ad. 1
Wyrażenie całej ścieżki przetwarzania (od wysłania requesta do odebrania responsa) w postaci strumienia danych nie służy tylko optymalizacji zużycia zasobów, ale pozwala na używanie i propagowanie back-pressure w każdym komponencie tego strumienia. Przykładowy use case: back-pressure zgłaszany na poziomie bazy danych będzie propagowany w górę (tj. upstream) aż do warstwy transportowej, gdzie zostanie następnie wyrażony w postaci TCP flow control. InnymiPokaż całość

@Patres: Funkcja, której szukasz, nazywa sie fold. Niestety nie jest ona dostępna w Javowym Optionalu :( W Scali wyglądałoby to tak:

Option(list).filter(_.nonEmpty).fold("nic")(_.mkString(", "))

@podubin: Problem w tym że jeżeli już używa się Springa, to niestety bardzo ciężko uniezależnić od niego nasz kod ;) Ale w ogólności Twoja zasada jak najbardziej jest słuszna.

@SuppressWarnings: Jeżeli coś tak błahego rzuca wyjątek, to niezbyt dobrze świadczy to o designie metody Set.of(...).

@Fensi: Ten kod to tylko uproszczony przykład, pokazujący patologiczne zachowanie metody Set.of. Łatwo sobie wyobrazić jak szybko coś takiego kopnęłoby nas w dupę w jakiejś większej aplikacji.

@MaFiGat: Set jest po to żeby reprezentować zbiór elementów bez duplikatów, a nie po to żeby zastawiać pułapki na programistów. Unikalność ma być gwarantowana na poziomie wewnętrznego stanu struktury danych, a nie na poziomie API.

@MaFiGat: Ale ja wiem jak to rozwiązać, problem w tym że nie widzę powodu żeby tak to wszystko komplikować. Oczekiwałbym że Set.of(...) będzie pozwalało w zwięźlejszy sposób osiągnąć to co da się zrobić za pomocą HashSetu i operacji .add(). Jeżeli taki był zamysł (a zakładam że tak było), no to się nie udało, bo działanie jednego i drugiego jest względem siebie niespójne (jedno pozwala wykonać dwukrotnie set.add() z tymPokaż całość

@MaFiGat: Ale przecież gdyby ten wyjątek nie był rzucany, a duplikaty by były po prostu ignorowane, to wyszłoby na to samo (tj. set byłby "od początku w porządku"). Jaki jest zatem sens istnienia tak nieintuicyjnej metody?

@Eoghan: Niestety niemutowalność nie ma tutaj absolutnie żadnego znaczenia. W programowaniu funkcyjnym struktury z natury są immutable, a mimo to operacja Set.of() w takiej postaci jak w Javie by nie przeszła (abstrahując od tego że ewentualne duplikaty na wejściu na pewno nie skutkowałyby wyjątkiem, ale przyjmijmy że zostajemy w Javowym świecie Exception Driven Development). Kluczowe jest tutaj coś o czym już wspomniałem, czyli wyraźna separacja API od wewnętrznego stanu danejPokaż całość

@Pan_Qcek: Unit testy testują logikę biznesową, a nie "najmniejsze możliwe rzeczy". Jeżeli masz testy na poziomie fasady/serwisu/komponentu, ale nie wykonujesz operacji I/O (a zamiast tego pod spodem uderzasz np. do repozytorium, które jest w pamięci), to nadal takie testy są testami jednostkowymi (mimo że logika, którą testujesz, znacznie wykracza poza pojedyncze funkcje o których mówisz).

@Bruno_: Jeżeli chodzi o testowanie aplikacji Springowych to mam dla Ciebie dwie wiadomości:Pokaż całość

@Myzreal: Nie jestem pewien jak dosłownie mam traktować Twoje zdanie: "mockując wszystkie jego zależności". Zakładając że mamy następujący graf zależności:
* ProductController -> ProductFacade -> ProductService -> ProductRepository
to czy jeżeli testujesz ProductFacade, to czy ProductService jest zamockowany czy nie?

@dog_meat: Dlaczego nie powinien testować czy coś faktycznie będzie uruchomione zgodnie z planem? W czym gorsze jest schedulowanie zadań od np. takiego zapisu do bazy danych, skoro to drugie powinien testować a tego pierwszego nie? Pamiętaj że to wcale nie oznacza testowania interfejsu zewnętrznej biblioteki, tylko tego czy Ty jako programista poprawnie tego interfejsu użyłeś.

@krasnoludkolo: Niestety nie wiem czy jest coś takiego w Javie, natomiast inspiracji możesz poszukaćPokaż całość

@krasnoludkolo: Update: widzę że jMock ma coś takiego jak DeterministicScheduler. Być może powinieneś popatrzeć w tym kierunku.

@dog_meat: W takim razie wstaw sobie w to miejsce cokolwiek innego, co testujesz jednostkowo, i powiedz w czym gorsze od tego jest schedulowanie zadań żeby go nie testować :P

@dog_meat: To czy cudzego interfejsu użyjesz z parametrem X lub Y, jest jak najbardziej częścią Twojej logiki, którą najzwyczajniej w świecie możesz testować jednostkowo. Nie sprawdzam wtedy twórców tego interfejsu, tylko sprawdzam siebie - czy poprawnie użyłem czyjegoś kodu. Przykładowo używając Javowego ScheduledExecutionService, nie sprawdzam czy ta abstrakcja działa poprawnie, tylko czy moje użycie tej abstrakcji jest poprawne (np. czy poprawnie zlecam jej coś do wykonania raz na 12h).