Java – cannot resolve any bean of type [org. GlassFish. Jersey. Message. Filtering. SPI. Objectprovider]
I tried to transfer from Moxy to Jackson JSON media provider to serve my jersey network, and found several problems I couldn't solve so far:
First of all, Moxy works well for the same piece of code, but because we use Jackson in other projects, I want to be consistent... So I changed
1) Dependence on POM
<dependency> <groupId>org.glassfish.jersey.media</groupId> <artifactId>jersey-media-json-jackson</artifactId> <version>${jersey.version}</version> </dependency>
2)ResourceConfig regester
register(JacksonFeature.class)
But when I run my WebService, I start to get this exception (which basically happens when I return from a 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... Obviously we use wildfly as an application server if it's important
So it would be great if someone could point out my possible problems
Cheers!
Solution
The problem seems to occur in the filtering Jackson jaxbjsonprovider, which is Jersey's own Jackson provider because it supports entity data filtering It seems that some injection (calling weld) continues to cause it to fail If you don't need entity data filtering, you can get rid of Jersey media JSON Jackson instead of using it
<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 it will cause problems to you in the future, so I won't consider changing Jackson dependency. It's a solution, not a solution
You said in your comments that you were using GF CDI Maybe that's the problem This artifact is no longer generated after Jersey 2.14 (you use Jersey 2.17) CDI support module changed You can see 27.3 1. Release 2.15 Highlights. It mentions something about CDI support dependencies