Closed jerseyrobot closed 11 years ago
@glassfishrobot Commented Reported by @japod
@glassfishrobot Commented @japod said: updated title and description as the real cause popped to me in night
@glassfishrobot Commented @mpotociar said: Raising priority.
@glassfishrobot Commented @pavelbucek said:
@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());
}
});
}
@glassfishrobot Commented gorbachev said: What's the rationale for pushing a fix of this to 2.2?
When is 2.2 coming out?
@glassfishrobot Commented @japod said: This was already partially fixed in 2.1. Please see #2177. Until the original issue gets fully fixed in Jersey 2.2 (tracked , you will need to inject using tt>@Inject</tt directly to request scoped (the default scope) resource instance fields.
@glassfishrobot Commented @japod said: Fixed in the master branch.
@glassfishrobot Commented Issue-Links: depends on HK2-106 is duplicated by JERSEY-1764 is related to JERSEY-1342 is related to JERSEY-1967
@glassfishrobot Commented This issue was imported from java.net JIRA JERSEY-1761
@glassfishrobot Commented Marked as fixed on Wednesday, August 21st 2013, 7:48:21 am
Initially reported as a comment in #1614, related to proxiable request scope injectables, i.e. @Context UriInfo ui, when the injected proxies are being accessed from the code outside of request scope.
The only solution i have in mind is to avoid injecting proxies into request scoped targets, and only use them (proxies) when really needed (singleton targets).
Affected Versions
[2.0-m12, 2.0]