Hi Ian, Thank you for your quick reply. My original intention was to open a JIRA ticket, but I'm getting an authentication error, as I'm not a member of the JIRA project. That's why I chose to send this email instead. Is it possible to join the JIRA project or what is the correct procedure to open an issue there?
The code change to switch to explicit registration should be very straightforward: remove the file in META-INF and call mapper.registerModule(new JtsModule()); explicitly any time an ObjectMapper is created. The tricky part is that implementing projects (GeoServer, but also external users that have already migrated to GeoTools 35.0) that currently rely on the automatic discovery, will also need to make this change when creating their own ObjectMappers. This is a breaking change, but at the same time also allows them to only register the module for the ObjectMapper instances that are actually used for GeoJSON/JTS geometry mapping (and to exclude any Jackson 2 instances, thereby fixing the issue at hand). Bas Op ma 6 jul 2026 om 11:54 schreef Ian Turton <[email protected]>: > 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
