I think you are the first person to raise this issue, could you open a ticket for it on the jira along with your analysis.
How easy/hard would it be to change to explicit registration? I assume I chose automatic for a reason when I wrote that code but I can't recall what it was (or may be that was just the recommended way to do it) Ian On Mon, 6 Jul 2026 at 10:36, Bas Duineveld <[email protected]> wrote: > 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 > -- Ian Turton
_______________________________________________ GeoTools-GT2-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
