Great, thanks again Sergey! Envoyé de mon iPad
Le 9 juil. 2012 à 19:27, "Sergey Beryozkin" <[email protected]> a écrit : > Actually, I forgot to commit the actual changes to the test filter, > sorry about it, will be merging now :-) > > Sergey > On 09/07/12 13:20, Sergey Beryozkin wrote: >> 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 >>>>> > > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ > > Blog: http://sberyozkin.blogspot.com
