Hi,
Definitely sounds like the JAXRSInInterceptor needs to be moved a bit.
Which phase would you recommend ? Between RECEIVE and INVOKE phases we have
these phases
Phase.PRE_STREAM (this is where JAXRSInInterceptor currently lives)
Phase.USER_STREAM
Phase.POST_STREAM
Phase.READ
Phase.PRE_PROTOCOL
Phase.USER_PROTOCOL
Phase.POST_PROTOCOL
Phase.UNMARSHAL
Phase.PRE_LOGICAL
Phase.USER_LOGICAL
Phase.POST_LOGICAL
Phase.PRE_INVOKE
I'd allocate it a phase such that if users where to add CXF interceptors before/after JAXRSInInterceptor does its job, they'd use
the same phases they do when doing some custom pre/post processing with JAX-WS such that the same interceptor can be reused in both
jaxrs and jaxws request paths, with the same phases involved.
I think Phase.PRE_LOGICAL should fit. Or Phase.UNMARSHAL given that the out JAXRSOutInterceptor sits on the Phase.MARSHAL. What do
you think ?
Actually, I'm wondering if it's possible to split it up into a couple smaller
interceptors that can be distributed into the phases a bit better to make it
closer to the way the normal processing works? Do some work in one phase,
allow users to throw some interceptors in, do some more work, etc... That
should definitely make it more flexible, but I'm not sure how hard it would
be to do.
Sounds interesting.
JAXRSInInterceptor does these main tasks :
1. Preprocess uri (as per the 0.8 spec) - this requirement has been dropped but
it'll stay in CXF
2. Select a root resource class
3. Invoke on request filters - filters can be blocking if they return a
not-null Response or throw Exceptions
4. Select a method on the root resource class to be invoked
JAXRSInvoker proceeds from there, it invokes on a method and if this method is a subresource locator it continues invoking until the
final method has been invoked. I'm not sure yet how users would want to customize the request say between 3 and 4. But in principle
1&2 and 3&4 can be done in seperate input interceptors such that after 1&2 but before 3&4 a 'classical' CXF interceptor can be
plugged in and do some work instead of JAXRS filters. Lets see if some users would find the current 'monolitic' JAXRSInInterceptor a
bit inflexible. But the split is quite feasible.
About request filters. Once we update the JAXRSInInterceptor's phase users might be able to do some things JAXRS filters can do
using CXF interceptors - say they'd be able to modify the message, use features to add GZIP (in filters one needs to explicitly
replace an input stream in a message to do GZIP for ex - not difficult but a bit of etrra work in the code), etc. They will likely
be able to reuse the same interceptors between JAXWS and JAXRS.
JAXRS pre/post filters are handy is that they're more JAXRS-friendly in that one can block by throwing an exception and combine it
with a custom JAXRS ExceptionMapper, they can return a JAXRS Response and JAXRS field injection for things like UriInfo/etc, will be
supported for them too. I can see users focused mainly on JAX-RS doing them more often then CXF interceptors but one never knows
:-).
Cheers, Sergey
Dan
