Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.

Christian

Am Do., 3. Jan. 2019 um 18:24 Uhr schrieb Ron Sigal <rsigal@xxxxxxxxxx>:
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


--

Back to the top