What scope do JAX-RS 2 filters have?

Question

I am using RestEasy 3.0.2 which is one of the first JAX-RS 2 implementations and run my application within a Tomcat 7. I also make use of injection in my application via WELD which is integrated with RestEasy via its CDI adaptor. Everything works fine so far.

Now, I wrote an implementation of a ContainerRequestFilter to perform authentication of incoming requests before they hit a resource. The JAX-RS standard says that injection is possible for every resource and every other JAX-RS component that is annotated with a @Provider annotation.

Here is a simplified version of my filter implementation:

@Provider
@Priority(Priorities.AUTHENTICATION)
public class AuthenticationFilter implements ContainerRequestFilter {

    @Inject
    AuthenticationProvider authenticationProvider;

    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        authenticationProvider.authenticate(requestContext);
    }
}

Note: AuthenticationProvider is @RequestScoped.

In general, this solution works. The components are being injected and requests are being processed as expected.

But I am still in doubt in which scope the filter is living. If it was application-scoped then this would obviously lead to "funny" concurrency issues that cannot be found with deterministic tests.

I have looked into various documentation, guides and examples but I have found none that uses injection with filters or says something about the filter scope.

Why not to implement javax.servlet.Filter instead? It seems like a good match for what you are trying to achieve. — Alex P, Jul 27 '13 at 11:58
JAX-RS filters can be used as post-match filters meaning that you can apply them to specific resources via annotations or DynamicFeature implementations. The same is not possible with javax.servlet.Filter without resonable effort. — Chris B, Jul 27 '13 at 12:02

Chris B · Accepted Answer · 2013-08-01T14:04:58.737

For RestEasy, the answer is given in the RestEasy documentation concerning CDI integration:

A CDI bean that does not explicitly define a scope is @Dependent scoped by default. This pseudo scope means that the bean adapts to the lifecycle of the bean it is injected into. Normal scopes (request, session, application) are more suitable for JAX-RS components as they designate component's lifecycle boundaries explicitly. Therefore, the resteasy-cdi module alters the default scoping in the following way:

If a JAX-RS root resource does not define a scope explicitly, it is bound to the Request scope.

If a JAX-RS Provider or javax.ws.rs.Application subclass does not define a scope explicitly, it is bound to the Application scope.

Therefor JAX-RS filters annotated with @Provider are @ApplicationScoped.

The documentation also says that a JAX-RS provider can be associated with any scope by putting the proper annotation to it. So in general, the scope of a JAX-RS filter can be customized.

It is important to notice that it is safe to inject @RequestScoped objects into an @ApplicationScoped filter. This is, because CDI does not inject a reference to the actual object but to a proxy. When a method is invoked on the proxy, a separate instance of the object will be used for each request behind the scenes.

Here the according WELD documentation:

4.9. Client proxies

Clients of an injected bean do not usually hold a direct reference to a bean instance, unless the bean is a dependent object (scope @Dependent).

Imagine that a bean bound to the application scope held a direct reference to a bean bound to the request scope. The application-scoped bean is shared between many different requests. However, each request should see a different instance of the request scoped bean—the current one!

...

Therefore, unless a bean has the default scope @Dependent, the container must indirect all injected references to the bean through a proxy object. This client proxy is responsible for ensuring that the bean instance that receives a method invocation is the instance that is associated with the current context. The client proxy also allows beans bound to contexts such as the session context to be serialized to disk without recursively serializing other injected beans.

I used the following code to validate this (assume that the entityManager is produced as @RequestScoped in the example):

@Provider
public class OtherTestFilter implements ContainerRequestFilter {

    @Inject
    EntityManager entityManager;

    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        Session session =  (Session) entityManager.getDelegate();
        System.out.println(session.hashCode());
    }
}

This gives a different hash value of session for every request processed by the filter. So theory and practice match here.

Actually, it's entirely up to you what scope they'll have - just add a scope annotation to the class and see what happens. — John Ament, Jul 29 '13 at 01:29
You are right. I found an according information in the RestEasy docs that confirms your statement. — Chris B, Aug 01 '13 at 14:08

score 0 · Answer 2 · answered Jul 28 '13 at 00:48

0

The way it's defined, it looks like it is DependentScoped. The only other possibility would be a silent RequestScoped, but that isn't very likely.

answered Jul 28 '13 at 00:48

LightGuard

5,298
19
19

I also assume that the filter is DependentScoped as you say. At least it would make sense. However, it doesn't make a difference for the intent behind my answer which was whether the injection itself would be safe. Unfortunately I didn't make that clear enough I fear. Thanks for your answer anyway! – Chris B Jul 28 '13 at 18:59
DependantScope creates a new instance of the object every time it is injected. As long as what you are injecting it into is safe you should be fine. – LightGuard Jul 28 '13 at 22:53
I found out that filters are only instantiated during initialization and that no new instances are created later. This is intentionally. If you look on how filters are registered via DynamicFeature then you will notice that it was the authors' goal to move costly work like annotation processing to the registration phase of a filter. This makes only sense if filters are reused, because you may pass resource-dependent information to a filter's state which must be preserved for the whole lifecycle. – Chris B Jul 29 '13 at 05:58
In RestEasy the default scope is actually application scope according to the docs. See my answer for details. – Chris B Aug 01 '13 at 14:06

cassiomolin · Answer 3 · 2018-06-26T23:24:52.507

What scope do JAX-RS 2 filters have?

Providers such as filters are singleton by default.

What the documentation says

From the Application documentation:

The default life-cycle for resource class instances is per-request. The default life-cycle for providers (registered directly or via a feature) is singleton.

From the JAX-RS specification:

By default a single instance of each provider class is instantiated for each JAX-RS application. First the constructor is called, then any requested dependencies are injected, then the appropriate provider methods may be called multiple times (simultaneously), and finally the object is made available for garbage collection.

And the JAX-RS specification also mentions the following regarding CDI integration:

Providers and Application subclasses MUST be singletons or use application scope.

What scope do JAX-RS 2 filters have?

3 Answers3

What the documentation says

Linked