Fajnie, że jesteś 
Mam nadzieję, że poniższy artykuł przypadnie Ci do gustu. Nie przywiązuj zbyt dużej wagi do daty powstania tego wpisu. Nawet jeśli napisałem go na początku istnienia bloga, to staram się przynajmniej raz w roku przeglądać stare treści i je aktualizować. Jeżeli mimo wszystko zauważysz jakąś nieścisłość w tekście, to daj mi proszę znać w komentarzu poniżej.
Pamiętaj także, że wartość tego bloga podbijają pozostawione tu komentarze. Jeżeli temat poruszany we wpisie Cię interesuje, to polecam doczytać także komentarze do niego. Znajdziesz w nich chociażby punkt widzenia innych osób, czy dodatkowe informacje, o których ja zapomniałem lub nie wiedziałem.
W tym tygodniu nauczyłem się…
…że, UUID = 00000000-0000-0000-0000-000000000000 zniknie w czeluściach JSON-a, jeżeli jacksonowym ObjectMapperze ustawimy serialization inclusion na NON_EMPTY.
Long story short:
- Kolega Krzysztof zgłasza mi, że odpowiedź (w formacie JSON) na jednym z endpointów na środowisku DEV przestała zwracać pole
accountId.
- Sprawdzam. Faktycznie – nie ma. WTF?! Przecież to pole nie może być nullem…
- Debuguję. No jest. Na wyjściu z kontrolera mamy POJO, a w nim
accountId typu java.util.UUID z ustawioną wartością na 00000000-0000-0000-0000-000000000000. No ale w JSON-ie nie ma. WTFx2?!
- Na szczęście szybko dotarło do mnie, że niedawno dodawałem globalne ustawienie
objectMapper.setSerializationInclusion(NON_EMPTY).
- Wychodzi na to, że Jackson traktuje w/w UUID jako pusty. Wiadomo, to jest UUID stworzony z ręki, tylko dla uproszczenia na środowiskach developerskich. Ale skoro
java.util.UUID nie krzyczy, że nie jest on poprawny, to dlaczego Jackson się do niego nie przyznaje?
Przeczytaj także
Dodaj komentarz