Tak, nie wiem, dlaczego w tym samouczku używają wersji 2.9, ale w przypadku artefaktu jersey-media-json-jackson używają wersji 2.4.1. Generalnie powinieneś zachować wersje Jersey (powiązane artefakty) takie same. W rzeczywistości Github Project autor zmienił to, aby użyć projektu ${jersey.version} (który jest 2.14), co ma więcej sensu.
Ale, aby odpowiedzieć na twoje główne obawy, począwszy od wersji 2.9 moduł jersey-media-json-jackson bierze udział w AutoDiscoverable classpath scanning, który obejmuje Java's Service Provider mechanism. Możesz zobaczyć tę zmianę, przełączając się do wersji 2.8 i 2.9 (w górę) tego modułu. W pliku META-INF/services zobaczysz plik org.glassfish.jersey.internal.spi.Autodiscoverable (który zawiera implementację JacksonAutoDiscoverable) w wersji 2.9 (i wyższej). Dzięki temu funkcja nie musi być jawnie skonfigurowana, chyba że funkcja wykrywania automatycznego jest wyłączona (co jest możliwe do zrobienia).
I tylko pod względem kompletności, gdy masz Moxy na ścieżce klasy, a nie jawnie zarejestrować funkcję Jackson, Moxy zostaną wykorzystane, jak Moxy jest dostawcą domyślnym. Nawet jeśli nie masz wyraźnej zależności od MOXy, w sytuacjach takich jak użycie serwera Glassfish, ma on artefakt MOXy, w którym to przypadku możemy albo jawnie zarejestrować funkcję Jackson, która automatycznie wyłącza MOXy, albo możemy jawnie wyłączyć MOXy z właściwością ServerProperties.MOXY_JSON_FEATURE_DISABLE ustawioną na true
ah ... teraz wszystko ma sens. Dzięki! Zatem rejestracja klasy elementów w aplikacji byłaby częścią optymalizacji projektu. Ale oczywiście automatyczne wykrywanie ścieżki klasy powinno być wyłączone, aby zauważyć różnicę. Dzięki, peeskillet! –
Jeszcze raz dziękuję! Ta najnowsza edycja, którą dodałeś, jest cenna. Nigdy bym nie zgadł, jak bardzo jest zaangażowany w projekt oparty na Jersey. Dobry towar! –