Cannot resolve any beans for types [org.glassfish.jersey.message.filtering.spi.ObjectProvider <com.fasterxml.jackson.databind.ser.FilterProvider>]

Question

trying to migrate from Moxy to Jackson json media provider for my web service in Jersey and found a couple of problems that I still cannot solve:

moxy first worked perfectly for the same piece of code, but since we use jackson everywhere in other projects, I want everything to be consistent ... so I changed

1) dependence on pom to

<dependency> <groupId>org.glassfish.jersey.media</groupId> <artifactId>jersey-media-json-jackson</artifactId> <version>${jersey.version}</version> </dependency> 

2) RegConfig regester

 register(JacksonFeature.class) 

but I started getting this exception when I start my webservice (this mainly happens when I return from the web service method):

 Caused by: org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308: Unable to resolve any beans for Types: [org.glassfish.jersey.message.filtering.spi.ObjectProvider<com.fasterxml.jackson.databind.ser.FilterProvider>]; Bindings: [QualifierInstance{annotationClass=interface javax.enterprise.inject.Default, values={}, hashCode=48147280}] at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:815) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:75) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] at org.glassfish.jersey.jackson.internal.FilteringJacksonJaxbJsonProvider.writeTo(FilteringJacksonJaxbJsonProvider.java:130) [jersey-media-json-jackson-2.17.jar:] at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265) [jersey-common-2.17.jar:] at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250) [jersey-common-2.17.jar:] at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) [jersey-common-2.17.jar:] at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:106) [jersey-server-2.17.jar:] at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) [jersey-common-2.17.jar:] at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:86) [jersey-server-2.17.jar:] at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) [jersey-common-2.17.jar:] at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1128) [jersey-common-2.17.jar:] at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:664) [jersey-server-2.17.jar:] at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:421) [jersey-server-2.17.jar:] at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:411) [jersey-server-2.17.jar:] at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:308) [jersey-server-2.17.jar:] at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [jersey-common-2.17.jar:] at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [jersey-common-2.17.jar:] at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [jersey-common-2.17.jar:] at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [jersey-common-2.17.jar:] at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [jersey-common-2.17.jar:] at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [jersey-common-2.17.jar:] at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:288) [jersey-server-2.17.jar:] at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1110) [jersey-server-2.17.jar:] at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:401) [jersey-container-servlet-core-2.17.jar:] ... 29 more 

yes ... and apparently we are using WildFly as an application server, if that matters.

So, if someone can tell me where the problem might be, that would be awesome.

Hooray!

Answer 1

The problem appears to occur in FilteringJacksonJaxbJsonProvider , which is Jackson's provider in Jersey, as it supports its Filtering Entity Data . There seems to be some injection (causing Weld), which leads to a crash. If you don’t need an entity data filtering function, you can get rid of jersey-media-json-jackson and use instead

 <dependency> <groupId>com.fasterxml.jackson.jaxrs</groupId> <artifactId>jackson-jaxrs-json-provider</artifactId> <version>${jackson2.version}</version> </dependency> // as of now ${jackson2.version} == 2.5.3 

As for the Weld problem, I'm not sure if this will cause a problem for you in the future, so I would not consider the Jackson dependency problem, not a workaround.

You said in your comments that you were using gf-cdi . Perhaps this is the problem. This artifact is no longer produced after Jersey 2.14 (you are using Jersey 2.17). The CDI support module has changed. You can see 27.3.1. Issue 2.15 Highlights . It mentions some things about CDI support dependencies.

The improved CDI support caused breaking changes for those users who directly link to the following CDI, which supports maven's Jersey module:

 <dependency> <groupId>org.glassfish.jersey.containers.glassfish</groupId> <artifactId>jersey-gf-cdi</artifactId> <version>${pre-2.15-version}</version> </dependency> 

The above dependency should be replaced by:

 <dependency> <groupId>org.glassfish.jersey.ext.cdi</groupId> <artifactId>jersey-cdi1x</artifactId> <version>2.17</version> </dependency> 

In addition, if you want to use CDI JTA support, you must add the following:

 <dependency> <groupId>org.glassfish.jersey.ext.cdi</groupId> <artifactId>jersey-cdi1x-transaction</artifactId> <version>2.17</version> </dependency> 

Answer 2

I was able to solve this by simply putting "Accept: application / xml" in the request. I also used the @Consumes annotation as shown in the screenshot.