Hi Anthony
On 05/07/12 21:53, Muller, Anthony wrote:
Thanks for all these informations Sergey, your help is very appreciated!
No problems :-), please see some comments below
Anthony
Envoyé de mon iPad
Le 5 juil. 2012 à 17:37, "Sergey Beryozkin"<[email protected]> a écrit :
Hi Anthony
Sorry for a delay
On 05/07/12 15:50, Muller, Anthony wrote:
Sergey,
More particularly, could you confirm handleRequest ans handleResponse will
still be called before and after any REST calls?
I don't like to have a lock never removed! :)
As it happens at the moment, if the exception is thrown during a call to
the resource method, then the out filters (ResponseHandler) are not
called so effectively a lock will stay where it is at the moment.
It appears things are not going to easy for you :-).
Few options are still available but given the fact you can not use
Spring and that CXF 2.3.x has been made obsolete makes it a bit tricky
to plan for a best approach.
First of all, regarding that missing path parameter. I'll write a test
later on and fix if needed, but your custom approach to do with parsing
the URI looks OK.
Now, using the custom invoker would be perfect in this case because the
exceptions will be caught early. But the fix I will apply to get
CXFNonSpringJAXRSServlet accept custom invokers won't make it to 2.3.8.
Next is the possible workaround where your resource method makes sure
that no exception ever escapes it: returning Response which will have a
proper status code set will be the easiest way to achieve it
Next option is to have your composite filter also implement CXF
OutFaultInterceptor, example:
http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/CustomOutFaultInterceptor.java
and register it as jaxrs:outFaultInterceptors, however I can see
CXFNonSpringJAXRSServlet does only recognizes in/out interceptors but
not fault ones.
So I think right now the best approach, given that you can not use
Spring/Blueprint, is to have the resource method which is being locked
ensure that no exception escapes and use the current filter implementation.
I'll take care of fixing CXFNonSpringJaxrsServlet to recognize custom
invokers and fault interceptors,
that is supported with "jaxrs.invoker" and "jaxrs.outFaultInterceptors",
starting from CXF 2.4.9-SNAPSHOT
and check why UriInfo.getPathParameters
does not return the parameters as expected
That actually works for me, please see the update to the test filter
from the revision history at
https://issues.apache.org/jira/browse/CXF-4413
For UriInfo.getPathParameters to return a non-empty map (either from
within the filter code or the actual resource method code), there has to
be a *matching* resource method available, with its @Path having at
least one template variable. May be there are some issues to do with
getting the path parameters from UriInfo in CXF 2.3.8, but things work
as expected in later versions
Cheers, Sergey
Anthony
