Dear GeoTools developers, I am a developer at the Dutch National Road Traffic Data Portal ( https://english.ndw.nu/). I'm currently in the process of upgrading my team's applications from GeoTools 34.4 to 35.0, and I have encountered what appears to be an interoperability issue related to the gt-geojson-core module.
As I understand it, gt-geojson-core includes a fork of the com.bedatadriven:jackson-datatype-jts library, which in version 35.0 has been migrated to Jackson 3. The JAR also contains the following ServiceLoader registration: META-INF/services/com.fasterxml.jackson.databind.Module with the contents: com.bedatadriven.jackson.datatype.jts.JtsModule The problem arises in applications that, during the transition to Jackson 3, still legitimately contain both Jackson 2 and Jackson 3 on the classpath. In our case, GeoTools uses Jackson 3, while other dependencies (for example Karate and GraphHopper) still depend on Jackson 2. Jackson 2's ObjectMapper.findModules() / findAndRegisterModules() uses ServiceLoader to discover all providers of com.fasterxml.jackson.databind.Module. It therefore finds the JtsModule provided by gt-geojson-core and attempts to load it. However, because JtsModule extends the Jackson 3 version of SimpleModule, it is not assignable to the Jackson 2 Module class, resulting in an exceptions like: java.util.ServiceConfigurationError: com.fasterxml.jackson.databind.Module: com.bedatadriven.jackson.datatype.jts.JtsModule not a subtype at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:593) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1244) at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273) at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309) at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393) at com.fasterxml.jackson.databind.ObjectMapper.findModules(ObjectMapper.java:1166) at com.fasterxml.jackson.databind.ObjectMapper.findModules(ObjectMapper.java:1150) at com.fasterxml.jackson.databind.ObjectMapper.findAndRegisterModules(ObjectMapper.java:1200) >From what I can tell, this is not specific to our application, but rather a consequence of both Jackson 2 and Jackson 3 using the same ServiceLoader entry while being binary incompatible. Would it make sense to reconsider the automatic ServiceLoader registration for this module? For example, requiring explicit registration of JtsModule where GeoTools configures its Jackson 3 ObjectMapper would avoid exposing the module to unrelated Jackson 2 instances elsewhere in the application. Alternatively, if there is already a recommended way to use GeoTools 35.0 in applications that temporarily need both Jackson major versions, I would be very interested to hear it. Is this a known issue, or is there a recommended migration strategy that I have overlooked? Thank you for your time and your work on GeoTools. Kind regards, Bas Duineveld
_______________________________________________ GeoTools-GT2-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
