I'm having trouble while creating two separate REST services with
Jersey. I'm using Glassfish 3.1.2.
I encountered this problem in another application I'm busy with, but to
be certain I boiled it down to a very simple example that's easy to
reproduce.
I first created one enterprise application (TestEa), and then two web
applications (TestEa-war1 and TestEa-war2). I want each war to have the
following REST services available:
/TestEa-war1/webresources/generic
/TestEa-war2/webresources/generic
Their handler classes both look just about like this:
@Path("generic")
@RequestScoped
public class GenericResource {
@Context HttpServletRequest request;
@GET
@Produces("text/plain")
public String getXml() {
HttpSession s = request.getSession(); // Yes, I'm using
session so I am violating REST principles
return "Session object: " + s.toString();
}
}
On their own, they work just fine. However, when they're both
activated, only one the of them work, and I get the following error
when accessing the second one (i.e. /TestEa-war2):
java.lang.IllegalStateException: No thread local value in scope for
proxy of class $Proxy129
at
com.sun.jersey.server.impl.ThreadLocalInvoker.invoke(ThreadLocalInvoker
.java:93)
at $Proxy129.getSession(Unknown Source)
at
test.another.GenericResourceTwo.getXml(GenericResourceTwo.java:47)
at
test.another.GenericResourceTwo$Proxy$_$$_WeldClientProxy.getXml(Generi
cResourceTwo$Proxy$_$$_WeldClientProxy.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja
va:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
rImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMeth
odInvokerFactory.java:60)
at
com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethod
DispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatc
hProvider.java:185)
at
com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDisp
atcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at
com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRu
le.java:288)
at
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceC
lassRule.java:108)
at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHand
PathRule.java:147)
at
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(Roo
tResourceClassesRule.java:84)
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleReques
t(WebApplicationImpl.java:1469)
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleReques
t(WebApplicationImpl.java:1400)
at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest
(WebApplicationImpl.java:1349)
at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest
(WebApplicationImpl.java:1339)
at
com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.
java:416)
at
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletCo
ntainer.java:537)
at
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletCo
ntainer.java:708)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at
org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1
542)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVal
ve.java:281)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextVal
ve.java:175)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.jav
a:655)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
595)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav
a:161)
at
org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.jav
a:331)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
231)
at
com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.cal
l(ContainerMapper.java:317)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMa
pper.java:195)
at
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849
)
at
com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
at
com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilte
r.java:228)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProto
colChain.java:137)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:
104)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:
90)
at
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:7
9)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTas
k.java:54)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.ja
va:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPoo
l.java:532)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.j
ava:513)
at java.lang.Thread.run(Thread.java:680)
However, I did find out a possible solution - but maybe not optimal (I
haven't found any problems yet). If you do the following:
public String getXml(@Context HttpServletRequest hsr) {
Instead of injecting it using @Context as seen above, it works. Is this
a known problem - perhaps I should log an issue?