I have a small JAX-RS (Jersey 3.0.1) API running in a standalone Jetty 11 but want to use Weld 4.0.0 instead of HK2. The Jetty bootstraps the Weld context properly (Jetty module ci-decorate was installed as described in the Weld documentation)
WELD-ENV-001212: Jetty CdiDecoratingListener support detected, CDI injection will be available in Listeners, Servlets and Filters.
When it comes to call the API endpoint an exception occurs:
WARNING: The following warnings have been detected: WARNING: Unknown HK2 failure detected:
MultiException stack 1 of 1
org.jboss.weld.exceptions.IllegalStateException: WELD-001304: More than one context active for scope type jakarta.enterprise.context.RequestScoped
at org.jboss.weld.manager.BeanManagerImpl.internalGetContext(BeanManagerImpl.java:672)
at org.jboss.weld.manager.BeanManagerImpl.isContextActive(BeanManagerImpl.java:658)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:163)
at org.jboss.weld.contexts.unbound.DependentContextImpl.get(DependentContextImpl.java:64)
at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:694)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:717)
at org.jboss.weld.util.ForwardingBeanManager.getReference(ForwardingBeanManager.java:64)
at org.jboss.weld.bean.builtin.BeanManagerProxy.getReference(BeanManagerProxy.java:87)
at org.glassfish.jersey.ext.cdi1x.internal.CdiUtil.getBeanReference(CdiUtil.java:127)
at org.glassfish.jersey.ext.cdi1x.internal.AbstractCdiBeanSupplier$1.getInstance(AbstractCdiBeanSupplier.java:69)
at org.glassfish.jersey.ext.cdi1x.internal.AbstractCdiBeanSupplier._provide(AbstractCdiBeanSupplier.java:103)
at org.glassfish.jersey.ext.cdi1x.internal.RequestScopedCdiBeanSupplier.get(RequestScopedCdiBeanSupplier.java:46)
at org.glassfish.jersey.inject.hk2.InstanceSupplierFactoryBridge.provide(InstanceSupplierFactoryBridge.java:53)
at org.jvnet.hk2.internal.FactoryCreator.create(FactoryCreator.java:129)
My dependencies in the pom.xml look as follows:
<dependency>
<groupId>org.jboss.weld.servlet</groupId>
<artifactId>weld-servlet-core</artifactId>
<version>4.0.0.Final</version>
</dependency>
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>5.0.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>jakarta.ws.rs</groupId>
<artifactId>jakarta.ws.rs-api</artifactId>
<version>3.0.0</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>3.0.1</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.inject</groupId>
<artifactId>jersey-hk2</artifactId>
<version>3.0.1</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext.cdi</groupId>
<artifactId>jersey-weld2-se</artifactId>
<version>3.0.1</version>
</dependency>
For the Weld context there exists an empty beans.xml in folder webapp/WEB-INF/beans.xml declared with bean-discovery-mode="all".
The JAX-RS endpoint class is shown next:
import de.test.weld.service.AddressRepository;
import jakarta.inject.Inject;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;
#Path("address")
public class AddressApi {
#Inject
private AddressRepository addressRepository;
#GET
#Produces(MediaType.APPLICATION_JSON)
public String getAddress() {
return "{\"street\": \"" + addressRepository.getStreet(0) + "\", \"postcode\": \"" +
addressRepository.getPostcode(0) + "\", \"city\": \"" + addressRepository.getCity(0) + "\"}";
}
}
The bean AddressRepositoryImpl which I want to inject is annotated with #jakarta.inject.Singleton.
I would appreciate any hint so it works with CDI Weld.
The problem was the wrong dependency
<dependency>
<groupId>org.glassfish.jersey.ext.cdi</groupId>
<artifactId>jersey-weld2-se</artifactId>
<version>3.0.1</version>
</dependency>
which exists only for non-JEE environments, i.e. Java Standard Edition (SE) or non-webapps.
Then the following dependency was still missing:
<dependency>
<groupId>org.glassfish.jersey.ext.cdi</groupId>
<artifactId>jersey-cdi1x</artifactId>
<version>3.0.1</version>
</dependency>
Solution refers to: Jersey Github Issues
Related
I need to implement a rest service call in my WEB application. According to Oracle, Weblogic is supported and does not need to register (deploy) jax-rs, so I would like to use these Server libraries. I made a simple class by calling a service (get). I configured the dependencies in the project and deployed it on Weblogic. However, when deploying, the following error appears: java.lang.ClassCastException: Cannot cast org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider to org.glassfish.jersey.server.spi.ComponentProvider
Note: It worked using this link below (deploying the jar on the server) But I want to use the native libraries on Weblogic. Could someone help me please?
https://docs.oracle.com/middleware/1213/wls/RESTF/use-jersey20-ri.htm#RESTF297
Code example (Java)
String host = "https://swapi.dev/api/people/2/";
Client client = ClientBuilder.newBuilder().build();
WebTarget webTarget = client.target(host);
Builder builder = webTarget.request(MediaType.APPLICATION_JSON);
String result = builder.get(String.class);
pom.xml
<properties>
<primefaces.version>3.5.RC1</primefaces.version>
<jersey.version>2.21.1</jersey.version>
<jaxrs.version>2.0</jaxrs.version>
</properties>
<!-- JAX-RS -->
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>javax.ws.rs-api</artifactId>
<version>${jaxrs.version}</version>
<scope>provided</scope>
</dependency>
<!-- Jersey 2.21.1 -->
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>${jersey.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-server</artifactId>
<version>${jersey.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-client</artifactId>
<version>${jersey.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-multipart</artifactId>
<version>${jersey.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.jaxrs</groupId>
<artifactId>jackson-jaxrs-json-provider</artifactId>
<version>2.4.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.8.6</version>
</dependency>
weblogic.xml
<wls:weblogic-version>12.2.1.3</wls:weblogic-version>
<wls:context-root>RecebimentoMercadoriaWEB</wls:context-root>
<wls:library-ref>
<wls:library-name>jsf</wls:library-name>
</wls:library-ref>
<wls:container-descriptor>
<wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>
</wls:container-descriptor>
<wls:session-descriptor>
<wls:cookie-name>CookieRecebimentoMercadoria</wls:cookie-name>
</wls:session-descriptor>
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>javax.faces.*</wls:package-name>
<wls:package-name>com.sun.faces.*</wls:package-name>
<wls:package-name>com.sun.facelets.*</wls:package-name>
<wls:package-name>com.bea.faces.*</wls:package-name>
</wls:prefer-application-packages>
<wls:prefer-application-resources>
<wls:resource-name>javax.faces.*</wls:resource-name>
<wls:resource-name>com.sun.faces.*</wls:resource-name>
<wls:resource-name>com.sun.facelets.*</wls:resource-name>
<wls:resource-name>com.bea.faces.*</wls:resource-name>
<wls:resource-name>META-INF/services/javax.servlet.ServletContainerInitializer</wls:resource-name>
<wls:resource-name>META-INF/services/com.sun.faces.spi.FacesConfigResourceProvider</wls:resource-name>
</wls:prefer-application-resources>
</wls:container-descriptor>
On Weblogic 12.2.1.3 yo do not need to execute the procedure described by the link you have pointed, I mean the link below .
https://docs.oracle.com/middleware/1213/wls/RESTF/use-jersey20-ri.htm#RESTF297
This is because that link belongs to Oracle Weblogic 12.1.3 and there are several differences between Weblogic 12.1.3.0 and Weblogic 12.2.1.3.
Furthermore, this document for Oracle Weblogic 12.2.1.3 states.
Note:
Jersey 2.x (JAX-RS 2.0 RI) support is provided by default in this
release of WebLogic Server. Registration as a shared library is no
longer required.
This means, when it comes to Weblogic 12.2.1.3 Jersey libraries are in place and ready to be used. Thus, your application should be able to use them.
However, I think server libraries are getting troubles with the libraries you are using within your pom.xml file.
Furthermore Oracle Weblogic 12.2.1.3 provides jersey 2.22.4
I have also used wls-cat in one of my servers to know, which library is loading the class org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider and I have found the library in $ORACLE_HOME/oracle_common/modules/org.glassfish.jersey.ext.cdi.jersey-cdi1x.jar, which means it is loaded by Weblogic as is stated on above documentation.
Furthermore, after running wls-cat I can see this:
org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider implements org.glassfish.jersey.server.spi.ComponentProvider
Thus, cast should not be an issue, which means there is a class loading problem that most probably is caused by libraries included in your application.
You can see the results of wls-cat executed on my server on below picture
You can use wls-cat to see which file (a JAR library) is loading the conflicting class. In below post you will find information about how to use wls-cat to analyse class loading problems.
https://blog.sysco.no/class/loader/AnalysingClassLoadingConflicts/
The libraries were really conflicting. I removed these dependencies from pom.xml and it worked. Thanks for the tip.
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-server</artifactId>
<version>${jersey.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>${jersey.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-multipart</artifactId>
<version>${jersey.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.jaxrs</groupId>
<artifactId>jackson-jaxrs-json-provider</artifactId>
<version>2.4.1</version>
<scope>provided</scope>
</dependency>
I have spring test-case as shown below when I run it is not starting the Netty server and provides following exception.
Caused by: org.springframework.context.ApplicationContextException: Unable to start web server; nested exception is org.springframework.context.ApplicationContextException: Unable to start ServletWebServerApplicationContext due to missing ServletWebServerFactory bean.
at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.onRefresh(ServletWebServerApplicationContext.java:155)
Below is my test case:
#RunWith(SpringRunner.class)
#SpringBootTest(classes = SpringWebFluxDemoApplication.class, webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT)
public class CustomPriceControllerTest {
#Autowired
private ApplicationContext context;
private WebTestClient testClient;
#Before
public void init() {
testClient = WebTestClient.bindToApplicationContext(context).configureClient().baseUrl("http://localhost:8080").responseTimeout(Duration.ofSeconds(30)).build();
}
#Test
public void broadcastVoltageConsumption() {
this.testClient.get().uri("/api/getCustomPrice")
.accept(MediaType.APPLICATION_STREAM_JSON)
.exchange()
.expectBodyList(Custom.class)
.consumeWith((customResults) -> {
List<Custom> list = CustomResults.getResponseBody();
Assert.assertTrue(list != null && list.size() > 0);
});
}
}
My pom.xml has excluded the dependency for tomcat to enable Netty. My Spring boot class works perfectly fine. It boots Netty server.
Update - pom.xml
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-rest</artifactId>
<exclusions>
<!-- Exclude the Tomcat dependency -->
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-webflux</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.projectreactor</groupId>
<artifactId>reactor-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
Had to add javax.servlet-api because I was facing issues with javax.servlet-api missing.
Update - 2
Removing the javax.servlet dependency from pom.xml solves the issue.
While when I try to run my main application it starts the Netty server normally. What is missing in this configuration? Can anyone help on this?
You wanted the webserver to be powered by Netty, but the exception you are getting is Servlet Specific
Since Netty is not servlet based technology, it seems you that somewhere (gradle/maven/#Configuration) you are mixing them,
so , just remove all references to Servlet dependencies and re try
If any dependency needs a servlet, it will force Jetty to come up and netty will never start in that case.
Whenever you see webflux is starting Jetty and not netty, you should run following command and then search who is including Jetty as dependency then you will find the answer.
./gradlew dependencies
In your case, you are including servlet dependency directly which is causing that issue.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<scope>test</scope>
</dependency>
I had the same issue. I just remove this dependency (which have servlet dependency):
testCompile('org.springframework.restdocs:spring-restdocs-mockmvc')
I'm currently running Jersey 2.25.1 in a Tomcat 8.5 container with Weld 3, but fail updating to Jersey 2.26. The problem seems to be the changed hk2 integration. If I try to use the old way, simply adding jersey-hk2:
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.26</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext.cdi</groupId>
<artifactId>jersey-cdi1x</artifactId>
<version>2.26</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext.cdi</groupId>
<artifactId>jersey-cdi1x-servlet</artifactId>
<version>2.26</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.inject</groupId>
<artifactId>jersey-hk2</artifactId>
<version>2.26</version>
</dependency>
I get a exception:
java.lang.AssertionError: parent must be a org.jvnet.hk2.internal.ServiceLocatorImpl instead it is a org.glassfish.hk2.api.ServiceLocator_$$_jvst4f9_0
at org.jvnet.hk2.external.generator.ServiceLocatorGeneratorImpl.initialize(ServiceLocatorGeneratorImpl.java:64)
at org.jvnet.hk2.external.generator.ServiceLocatorGeneratorImpl.jrCreate(ServiceLocatorGeneratorImpl.java:103)
at org.jvnet.hk2.external.generator.ServiceLocatorGeneratorImpl.create(ServiceLocatorGeneratorImpl.java)
at org.glassfish.hk2.internal.ServiceLocatorFactoryImpl.internalCreate(ServiceLocatorFactoryImpl.java:312)
at org.glassfish.hk2.internal.ServiceLocatorFactoryImpl.create(ServiceLocatorFactoryImpl.java:268)
at org.glassfish.jersey.inject.hk2.AbstractHk2InjectionManager.createLocator(AbstractHk2InjectionManager.java:114)
at org.glassfish.jersey.inject.hk2.AbstractHk2InjectionManager.<init>(AbstractHk2InjectionManager.java:86)
at org.glassfish.jersey.inject.hk2.ImmediateHk2InjectionManager.<init>(ImmediateHk2InjectionManager.java:62)
at org.glassfish.jersey.inject.hk2.Hk2InjectionManagerFactory$Hk2InjectionManagerStrategy$1.createInjectionManager(Hk2InjectionManagerFactory.java:79)
at org.glassfish.jersey.inject.hk2.Hk2InjectionManagerFactory.create(Hk2InjectionManagerFactory.java:97)
at org.glassfish.jersey.internal.inject.Injections.createInjectionManager(Injections.java:93)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.<init>(ResourceMethodInvoker.java:253)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.<init>(ResourceMethodInvoker.java:104)
at org.glassfish.jersey.server.model.ResourceMethodInvoker$Builder.build(ResourceMethodInvoker.java:218)
at org.glassfish.jersey.server.internal.routing.RuntimeModelBuilder.createInflector(RuntimeModelBuilder.java:130)
at org.glassfish.jersey.server.internal.routing.RuntimeModelBuilder.createMethodRouter(RuntimeModelBuilder.java:117)
at org.glassfish.jersey.server.internal.routing.RuntimeModelBuilder.createResourceMethodRouters(RuntimeModelBuilder.java:311)
at org.glassfish.jersey.server.internal.routing.RuntimeModelBuilder.buildModel(RuntimeModelBuilder.java:175)
at org.glassfish.jersey.server.internal.routing.Routing$Builder.buildStage(Routing.java:247)
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:422)
at org.glassfish.jersey.server.ApplicationHandler.lambda$initialize$1(ApplicationHandler.java:316)
at org.glassfish.jersey.internal.Errors.process(Errors.java:316)
at org.glassfish.jersey.internal.Errors.process(Errors.java:298)
at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:256)
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:315)
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:282)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:335)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:178)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:370)
The new jersey-cdi2-se dependency seems to be working only if you are not already have a weld container running.
I am not using servlet integration, just Grizzly http server, though I needed an additional dependency (same Jersey version as you):
<dependency>
<!-- Jersey integration with Weld -->
<groupId>org.glassfish.jersey.ext.cdi</groupId>
<artifactId>jersey-weld2-se</artifactId>
</dependency>
A part of our application which calls a REST webservice using Jersey Client 2.15 stopped working after we upgraded our Weblogic to Weblogic 12C - 12.1.3.0.0.
The exception trace we were getting was:
java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri(Ljava/lang/String;)Ljavax/ws/rs/core/UriBuilder;
at javax.ws.rs.core.UriBuilder.fromUri(UriBuilder.java:119)
at org.glassfish.jersey.client.JerseyWebTarget.<init>(JerseyWebTarget.java:71)
at org.glassfish.jersey.client.JerseyClient.target(JerseyClient.java:185)
at org.glassfish.jersey.client.JerseyClient.target(JerseyClient.java:70)
We were sure that it was a javax.ws.rs mismatch between Jersey and Weblogic WS libraries.
Dependencies
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-client</artifactId>
<version>2.15</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-common</artifactId>
<version>2.15</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>javax.ws.rs-api</artifactId>
<version>2.0.1</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.4</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.connectors</groupId>
<artifactId>jersey-apache-connector</artifactId>
<version>2.15</version>
</dependency>
Not longer did we realize that following our application logs with the above stack trace was misleading. So we started looking into Weblogic logs. The domain log did in fact gave as a totally different stack trace:
java.lang.NoSuchMethodError: org.glassfish.hk2.api.ServiceLocatorFactory.create(Ljava/lang/String;Lorg/glassfish/hk2/api/ServiceLocator;Lorg/glassfish/hk2/extension/ServiceLocatorGenerator;Lorg/glassfish/hk2/api/ServiceLocatorFactory$CreatePolicy;)Lorg/glassfish/hk2/api/ServiceLocator;
at org.glassfish.jersey.internal.inject.Injections._createLocator(Injections.java:138)
at org.glassfish.jersey.internal.inject.Injections.createLocator(Injections.java:109)
at org.glassfish.jersey.internal.RuntimeDelegateImpl.<init>(RuntimeDelegateImpl.java:63)
at
So after some firefighting and playing around with weblogic.xml and package overrides the issue was sorted. The following were the final package overrides which actually did solve the problem:
<wls:package-name>com.sun.jersey.*</wls:package-name>
<wls:package-name>org.glassfish.jersey.*</wls:package-name>
<wls:package-name>org.glassfish.hk2.*</wls:package-name>
<wls:package-name>org.jvnet.hk2.*</wls:package-name>
<wls:package-name>jersey.repackaged.org.objectweb.asm.*</wls:package-name>
<wls:package-name>org.objectweb.asm.*</wls:package-name>
<wls:package-name>com.sun.ws.rs.ext.*</wls:package-name>
<wls:package-name>javax.ws.rs.*</wls:package-name>
I'm trying to run a a test that extends JerseyTest but when running it I'm getting a:
java.lang.NoClassDefFoundError: jersey/repackaged/com/google/common/collect/Maps
Any idea what dependency I'm missing? I've included the following jersey artifacts in my pom.xml and jersey.version is 2.5.1:
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-client</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>com.sun.jersey.jersey-test-framework</groupId>
<artifactId>jersey-test-framework-core</artifactId>
<version>1.18</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.test-framework.providers</groupId>
<artifactId>jersey-test-framework-provider-grizzly2</artifactId>
<version>2.6</version>
<scope>test</scope>
</dependency>
You'll need:
<dependency>
<groupId>org.glassfish.jersey.bundles.repackaged</groupId>
<artifactId>jersey-guava</artifactId>
<version>2.6</version>
</dependency>
From http://blog.dejavu.sk/2014/02/21/jersey-2-6-has-been-released-new-and-noteworthy/
Jersey, from versions 2.6 for JAX-RS 2.0 and 1.18.1 for JAX-RS 1.1, no longer transitively brings Guava and ASM libraries to your application. This means that even when we still use them internally you can use different versions of these libraries. Classes from both of these libraries has been repackaged, jersey.repackaged.com.google.common and jersey.repackaged.objectweb.asm respectively, and shrinked to lower the footprint. ASM 5 is now part of jersey-server core module and for Guava we’ve created a separate bundle module jersey-guava as this dependency is widely used in multiple Jersey modules.
You're using the Jersey 2.6 jersey-test-framework-provider-grizzly2.