Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0-m13, 2.0
    • Component/s: core
    • Labels:
      None

      Description

      Once working, unignore org.glassfish.jersey.tests.e2e.entity.InjectedProvider test to confirm it is really working (the test is trying to inject UriInfo into a message body worker).

        Issue Links

          Activity

          Hide
          t.broyer added a comment -

          Migrating from 2.0-m12 to 2.0-m12-1, my async responses that make use of UriInfo all start to fail (see stacktrace below)

          févr. 26, 2013 3:54:28 PM com.google.common.util.concurrent.ExecutionList$RunnableExecutorPair execute
          SEVERE: RuntimeException while executing runnable com.google.common.util.concurrent.Futures$6@3bf67d5f with executor com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService@33a106ba
          java.lang.IllegalStateException: Not inside a request scope.
          	at com.google.common.base.Preconditions.checkState(Preconditions.java:149)
          	at org.glassfish.jersey.process.internal.RequestScope.current(RequestScope.java:225)
          	at org.glassfish.jersey.process.internal.RequestScope.findOrCreate(RequestScope.java:153)
          	at org.jvnet.hk2.internal.MethodInterceptorImpl.intercept(MethodInterceptorImpl.java:77)
          	at org.jvnet.hk2.internal.Utilities$MethodInterceptorInvocationHandler.invoke(Utilities.java:2230)
          	at sun.proxy.$Proxy46.getBaseUriBuilder(Unknown Source)
          …
          	at com.google.common.collect.Iterators$9.transform(Iterators.java:893)
          	at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
          	at com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:266)
          	at com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:223)
          …
          	at com.google.common.util.concurrent.Futures$6.run(Futures.java:799)
          	at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:262)
          	at com.google.common.util.concurrent.ExecutionList$RunnableExecutorPair.execute(ExecutionList.java:149)
          	at com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:134)
          	at com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:175)
          	at com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53)
          …
          	at org.glassfish.jersey.client.JerseyInvocation$7.completed(JerseyInvocation.java:902)
          	at org.glassfish.jersey.client.ClientRuntime$1$1$1.run(ClientRuntime.java:137)
          	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:294)
          	at org.glassfish.jersey.client.ClientRuntime$3.run(ClientRuntime.java:179)
          	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
          	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
          	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
          	at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:262)
          	at com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:43)
          	at com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:40)
          	at org.glassfish.jersey.client.ClientRuntime.submit(ClientRuntime.java:176)
          	at org.glassfish.jersey.client.ClientRuntime.access$300(ClientRuntime.java:67)
          	at org.glassfish.jersey.client.ClientRuntime$1$1.response(ClientRuntime.java:126)
          	at org.glassfish.jersey.client.HttpUrlConnector$2.run(HttpUrlConnector.java:212)
          	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
          	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
          	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
          	at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:262)
          	at com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:43)
          	at org.glassfish.jersey.client.HttpUrlConnector.apply(HttpUrlConnector.java:208)
          	at org.glassfish.jersey.client.ClientRuntime$1.run(ClientRuntime.java:156)
          	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
          	at org.glassfish.jersey.client.ClientRuntime$2.run(ClientRuntime.java:170)
          	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
          	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
          	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
          	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
          	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
          	at java.lang.Thread.run(Thread.java:722)
          

          Note: my JAX-RS resources are making async calls using the JAX-RS async client API, and tries to construct links using the UriInfo from the InvocationCallback's completed. More precisely, but it shouldn't matter here, the InvocationCallback is setting the value of a SettableFuture that my resource is listening (Futures.addCallback), and the UriInfo is used from the FutureCallback's onSuccess.

          Other resources where I do JAX-RS async client calls but do not use UriInfo complete without error.

          Looking at the diff between 2.0-m12 and 2.0-m12-1 (https://github.com/jersey/jersey/compare/2.0-m12...2.0-m12-1) it seems to be due to this specific change (https://github.com/jersey/jersey/commit/31282668a10fc115686fd6d4c181380b9bac5ee8) which references this issue.

          The "Fix version" field is set to 2.0-m13 but I don't see any commit in the 2.0-m12-1...master diff that references this issue or would fix the issue I'm encountering.

          Show
          t.broyer added a comment - Migrating from 2.0-m12 to 2.0-m12-1, my async responses that make use of UriInfo all start to fail (see stacktrace below) févr. 26, 2013 3:54:28 PM com.google.common.util.concurrent.ExecutionList$RunnableExecutorPair execute SEVERE: RuntimeException while executing runnable com.google.common.util.concurrent.Futures$6@3bf67d5f with executor com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService@33a106ba java.lang.IllegalStateException: Not inside a request scope. at com.google.common.base.Preconditions.checkState(Preconditions.java:149) at org.glassfish.jersey.process.internal.RequestScope.current(RequestScope.java:225) at org.glassfish.jersey.process.internal.RequestScope.findOrCreate(RequestScope.java:153) at org.jvnet.hk2.internal.MethodInterceptorImpl.intercept(MethodInterceptorImpl.java:77) at org.jvnet.hk2.internal.Utilities$MethodInterceptorInvocationHandler.invoke(Utilities.java:2230) at sun.proxy.$Proxy46.getBaseUriBuilder(Unknown Source) … at com.google.common.collect.Iterators$9.transform(Iterators.java:893) at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48) at com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:266) at com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:223) … at com.google.common.util.concurrent.Futures$6.run(Futures.java:799) at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:262) at com.google.common.util.concurrent.ExecutionList$RunnableExecutorPair.execute(ExecutionList.java:149) at com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:134) at com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:175) at com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53) … at org.glassfish.jersey.client.JerseyInvocation$7.completed(JerseyInvocation.java:902) at org.glassfish.jersey.client.ClientRuntime$1$1$1.run(ClientRuntime.java:137) at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:294) at org.glassfish.jersey.client.ClientRuntime$3.run(ClientRuntime.java:179) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:262) at com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:43) at com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:40) at org.glassfish.jersey.client.ClientRuntime.submit(ClientRuntime.java:176) at org.glassfish.jersey.client.ClientRuntime.access$300(ClientRuntime.java:67) at org.glassfish.jersey.client.ClientRuntime$1$1.response(ClientRuntime.java:126) at org.glassfish.jersey.client.HttpUrlConnector$2.run(HttpUrlConnector.java:212) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:262) at com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:43) at org.glassfish.jersey.client.HttpUrlConnector.apply(HttpUrlConnector.java:208) at org.glassfish.jersey.client.ClientRuntime$1.run(ClientRuntime.java:156) at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) at org.glassfish.jersey.client.ClientRuntime$2.run(ClientRuntime.java:170) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang. Thread .run( Thread .java:722) Note: my JAX-RS resources are making async calls using the JAX-RS async client API, and tries to construct links using the UriInfo from the InvocationCallback 's completed . More precisely, but it shouldn't matter here, the InvocationCallback is setting the value of a SettableFuture that my resource is listening ( Futures.addCallback ), and the UriInfo is used from the FutureCallback 's onSuccess . Other resources where I do JAX-RS async client calls but do not use UriInfo complete without error. Looking at the diff between 2.0-m12 and 2.0-m12-1 ( https://github.com/jersey/jersey/compare/2.0-m12...2.0-m12-1 ) it seems to be due to this specific change ( https://github.com/jersey/jersey/commit/31282668a10fc115686fd6d4c181380b9bac5ee8 ) which references this issue. The "Fix version" field is set to 2.0-m13 but I don't see any commit in the 2.0-m12-1...master diff that references this issue or would fix the issue I'm encountering.
          Hide
          Jakub Podlesak added a comment -

          To workaround untile this gets fixed, you should be able to extract the correct value from the proxy before the request processing gets suspended.
          Here is a simple example, as i do not know your exact use case:

          
          @GET
          public void asyncGet(@Context UriInfo ui, @Suspended final AsyncResponse response) {
          
                    final UriBuilder baseUriBuilder = ui.getBaseUriBuilder();
          
                    // now suspend and resume later on with
                    Executors.newSingleThreadExecutor().submit(new Runnable() {
          
                            @Override
                            public void run() {
                                  String hereWeGo = longRunningOp();
                                  ar.resume(baseUriBuilder.path(hereWeGo).build());
                            }
                     });
          }
          
          Show
          Jakub Podlesak added a comment - To workaround untile this gets fixed, you should be able to extract the correct value from the proxy before the request processing gets suspended. Here is a simple example, as i do not know your exact use case: @GET public void asyncGet(@Context UriInfo ui, @Suspended final AsyncResponse response) { final UriBuilder baseUriBuilder = ui.getBaseUriBuilder(); // now suspend and resume later on with Executors.newSingleThreadExecutor().submit( new Runnable () { @Override public void run() { String hereWeGo = longRunningOp(); ar.resume(baseUriBuilder.path(hereWeGo).build()); } }); }
          Hide
          Marek Potociar added a comment -

          Reopening as it seems the issue has not been fixed from the comments.

          Show
          Marek Potociar added a comment - Reopening as it seems the issue has not been fixed from the comments.
          Hide
          Marek Potociar added a comment -

          Actually I see there is a separate issue filed. Closing again.

          Show
          Marek Potociar added a comment - Actually I see there is a separate issue filed. Closing again.
          Hide
          t.broyer added a comment -

          Thanks Jakub, that does the trick. For completeness, it should be noted the UriBuilder has to be clone()}}d if used several times (i.e. replace {{uriInfo.getBaseUriBuilder() with uriBuilder.clone())

          Show
          t.broyer added a comment - Thanks Jakub, that does the trick. For completeness, it should be noted the UriBuilder has to be clone()}}d if used several times (i.e. replace {{uriInfo.getBaseUriBuilder() with uriBuilder.clone() )

            People

            • Assignee:
              Jakub Podlesak
              Reporter:
              Marek Potociar
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 18 hours Original Estimate - 18 hours
                18h
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 days, 5 hours, 30 minutes
                2d 5h 30m