jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: more interceptor discussions

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 24 May 2011 20:04:28 -0400

On 5/24/11 5:16 PM, Santiago Pericas-Geertsen wrote:
> Bill,
>
> Thanks for getting the discussion going and responding to the proposal. I think there's roughly 4 areas up for discussion: (i) interception points (ii) interceptor interfaces (iii) binding (iv) ordering.
>

We haven't talked about lifecycle yet. It can be important.

> Here is my take on these areas so far:
>
> (i) Interception points: I incorrectly attempted to determine these points while leaving the async case aside in my proposal, but clearly this is the wrong approach. After further analysis, I think the interception points in your proposal are spot on based on the use cases (except maybe for one, but I'll get back to it at some other point as I don't think it's that common).
>
> (ii) Interfaces: Clearly these will be derived from (i). Your proposal currently has 8 interfaces (excluding a base class): 2 handlers, 2 interceptors and 4 contexts. Using these interfaces will help you catch unwanted errors statically, but in the interest of simplicity we could cut this number in half and catch a few errors dynamically. I would opt for a solution with half the number of classes.
>

Reduction is good. I"m interested in seeing your ideas. Maybe
annotations can be used instead like EJB/CDI interceptors?

> (iii) Binding: I believe we should include a (server side) static binding mechanism using annotations (and meta-annotations) a la CDI, as described in my proposal. This seems to fit well in context of a JAX-RS application. Additionally supporting the AcceptedByMethod approach (dynamic binding) would be OK by me as well.
>

+1 to Both. FYI, all this fits very nicely with the client proxy
framework I've been talking about too.

> (iv) Ordering: As you pointed out in your blog, the numeric ordering approach in my proposal is a lot simpler. Yet, I believe there's something even better that we haven't explored. I think part of the complication is allowing users to define _custom precedence families_. Do you know of any Resteasy developers that use this feature?
>

Stick with your original simplicity, you were spot on. Precedence
families can be specified using constants, IMO.

public static HEADER_DECORATOR = 10;
public static DECODER = 100;


@ReaderInterceptor(order=DECODER)
public class GZIPDecoderInterceptor ... {
}

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com