Dominik Derwiński created WFLY-13000: ---------------------------------------- Summary: Put an end to problems with Jackson caused by jaxrs subsystem Key: WFLY-13000 URL: https://issues.redhat.com/browse/WFLY-13000 Project: WildFly Issue Type: Feature Request Components: REST Affects Versions: 18.0.1.Final Reporter: Dominik Derwiński Assignee: Alessio Soldano There is a serious problem with using bundled (inside ear) Jackson JSON library in version different than the one included inside WildFly. There are dozens of threads of people trying to solve this issue by manually upgrading modules in WildFly, excluding certain Jackson modules pulled by jaxrs and including them again in custom modules without exporting classes, to (finally) excluding the whole jaxrs subsystem, and using different implementation of JAXRS. Without doing so one can end with the following: {noformat} java.lang.NoSuchMethodError: 'com.fasterxml.jackson.core.TSFBuilder com.fasterxml.jackson.core.JsonFactory.builder()' {noformat} or {noformat} java.lang.IllegalAccessError: class com.fasterxml.jackson.core.JsonFactoryBuilder tried to access private field com.fasterxml.jackson.core.JsonFactory.DEFAULT_ROOT_VALUE_SEPARATOR (com.fasterxml.jackson.core.JsonFactoryBuilder is in unnamed module of loader 'deployment.xyz-ear-1.ear' @b6d0dc5; com.fasterxml.jackson.core.JsonFactory is in unnamed module of loader 'com.fasterxml.jackson.core.jackson-core(a)2.9.10' @68fc71cf) {noformat} Could this be fixed somehow by not exporting Jackson classes from jaxrs/resteasy/jackson2-provider modules? Why do they even get priority before classes from ear classloader? -- This message was sent by Atlassian Jira (v7.13.8#713008)