Here is a sample Resource class:
@Path("/resource")
public class SomeResource {
@GET
@Produces({MediaType.APPLICATION_XML})
public String someMethod(@QueryParam("param1") String param1, ..., @Context HttpServletRequest request) {
String remoteUser = request.getRemoteAddr();
// Business logic here.
return response;
}
}
And the JerseyTest for the resource:
public class TestSomeResource extends JerseyTest {
@Override
protected Application configure() {
enable(TestProperties.LOG_TRAFFIC);
return new ResourceConfig(SomeResource.class);
}
@Test
public void testXMLResponse() {
String response = target("resource")
.queryParam("param1", param1)
// More parameters here.
.request()
.accept(MediaType.APPLICATION_XML)
.get(String.class);
// Some assertions on response.
}
}
I am able to run jersey tests for all other resources except the ones using @Context HttpServletRequest
as an input parameter. It gives a InternalServerErrorException: HTTP 500 Internal Server Error.
Following is the stacktrace:
javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error
at org.glassfish.jersey.client.JerseyInvocation.convertToException(JerseyInvocation.java:904)
at org.glassfish.jersey.client.JerseyInvocation.translate(JerseyInvocation.java:749)
at org.glassfish.jersey.client.JerseyInvocation.access$500(JerseyInvocation.java:88)
at org.glassfish.jersey.client.JerseyInvocation$2.call(JerseyInvocation.java:650)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:228)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:421)
at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:646)
at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:375)
at org.glassfish.jersey.client.JerseyInvocation$Builder.get(JerseyInvocation.java:275)
at com.mysample.TestSomeResource.testXMLResponse(TestSomeResource.java:15)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Seems like this problem has been there since a long time ago. As @lpiepiora's explaination, we need a Servlet-based test container. And there already is one in
jersey-test-framework-provider-grizzly2
(don't know if there is it when the question posted), which isGrizzlyWebTestContainerFactory
, and it requires a differentDeploymentContext
. Pull the newest git and you'll find an example intest-framework/providers/grizzly2/src/test/java/org/glassfish/jersey/test/grizzly/web/GrizzlyWebTest.java
. To be straight and simple, you just need to add these overrides in your base test class:(Replace
YourResourceConfig
with your real one.)EDIT: If you use Jersey with
jersey-spring3
, you will find the solution above fails because of the absence of all your Spring beans. To fix it:You exception is related to the fact that the
HttpServletRequest
isnull
.Jersey documentation says:
I'm guessing that you use
jersey-test-framework-provider-grizzly2
which doesn't support it.If you want to have access to
HttpServletResponse
remove that dependency and add:Now you actually want to tell JerseyTest to start the right test server, to do that you have to override a method
protected TestContainerFactory getTestContainerFactory()
. Please be sure to replace<your-java-package>
with the actual name of your package.You can also check
org.glassfish.jersey.test.grizzly.GrizzlyTestContainerFactory
for better implementation of the factory.You can also inject a mocked HttpServletRequest object in the configure method. Here is an Jersey 1 example:
Jersey 2:
Also see peeskillet's answers on this stackoverflow thread: [link]
(none of the currently listed solutions worked for me)
So finally I get working solution (It close to most popular answer but with small changes):
pom.xml
Add following abstract class to application:
And to test Rest you need do like this:
The easier way is to provide correct factory in a test constructor:
and provide servlet context: