As plans are existing to replace JAX-RS's injection API by CDI I think it is not worth setting up a JAX-RS specific solution. We should speed up the transition to CDI to solve this. -Markus From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Christian Kaltepoth
Sent: Freitag, 4. Januar 2019 07:37
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Request for extension with Application interface The problem you are describing seems to be very specific to the native JAX-RS dependency injection via @Context, which we are planning to deprecate soon in favor of CDI. And CDI handles this situation much better, because it automatically injects proxies. Also, it feels weird to add an interface which is basically the same as the existing Application class. This doesn't bring any benefit for the user from an API perspective. It looks like it just addresses an implementation concern. And actually using Javassist in these situations is very common. Therefore, I'm unsure if we should really address this on the spec level. This issue came up in the context of
https://issues.jboss.org/browse/RESTEASY-1709 "Same JAX-RS Application
instance injected across applications".
Consider a WAR with two Application classes, Application1 and
Application2, both derived from ApplicationAbstract and both of which
reference a provider such as
@Provider
public class FooReader implements MessageBodyReader<Foo> {
@Context
ApplicationAbstract application;
...
}
The value of application should be either Application1 or Application2,
depending on the resource being called. In accordance with Section 4.1
"Lifecycle and Environment" of the JAX-RS 2.1 spec, which says, "By
default a single instance of each provider class is instantiated for
each JAX-RS application", RESTEasy creates two copies of FooReader at
initialization time and injects the appropriate Application.
The complication arises when CDI is activated. With respect to CDI, the
application scope of FooReader means that a single instance of FooReader
will be created for the lifetime of the WAR, and injection into the
application field will occur only once. Whichever value is injected will
be correct some of the time and incorrect some of the time.
The natural solution would be to inject a proxy which retrieves the
currently relevant Application, but, unfortunately, unlike all of the
other @Context injectable types, Application is a class instead of an
interface. In RESTEasy, we worked around that by using Javassist, which
is able to create proxies for classes. It would be preferable, though,
if it were possible to use pure Java proxies.
We propose something like
public interface ApplicationInt {
public Set<Class<?>> getClasses();
public Set<Object> getSingletons();
public Map<String, Object> getProperties();
}
public class Application implements ApplicationInt {
...
}
-Ron Sigal
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
-- |
