[ 
https://issues.apache.org/jira/browse/CXF-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628336#action_12628336
 ] 

Sergey Beryozkin commented on CXF-1730:
---------------------------------------

Hi Frank

> how was your holiday? 
thanks, it was good :-)

> First of all now it works. I've downloaded the 2.1.2 version and now it 
> works. So thanks for your help.

Unfortunately, even though it works, the fact that your filter depends on 
OperationResourceInfo be set
in the message makes your filter a bit brittle.

The problem is that selecting OperationResourceInfo before filters are invoked 
brings the necessity to reselect OperationResourceInfo after every individual 
filter is invoked - as an individual filter may have the Accept header value 
updated in the message - with this value affecting the selection of the 
OperationResourceInfo in the first place. In other words, you reckon that 
OperationResourceInfo you're dealing with in the filter represents the method 
which will be invoked upon - but it might not be the case - well at least in  
the looser environment.

I feel it would be better to do this kind of authentication using Spring AOP.  
This current dependency is a bit brittle - I may need to refactor for 2.1.3 it 
again (basically revert some of the changes that were needed for this JIRA be 
solved) - unless we find a smarter solution


> The Exception handling if it is thrown from a RequestHandler is not correct i 
> guess.
> ------------------------------------------------------------------------------------
>
>                 Key: CXF-1730
>                 URL: https://issues.apache.org/jira/browse/CXF-1730
>             Project: CXF
>          Issue Type: Bug
>          Components: REST
>    Affects Versions: 2.1.2
>         Environment: Windows XP,  jdk1.6, Apache Tomcat 6.0.16
>            Reporter: Frank Ittermann
>            Assignee: Daniel Kulp
>             Fix For: 2.1.2
>
>
> Hello again
> i' ve used an implementation of RequestHandler to perform authentication 
> stuff. So
> if the Authentication failed a RuntimeException is thrown.  I've also wrote a 
> ExceptionMapper implementation to transform occurred Exception into Http 
> Status codes. If the RuntimeException from the Authentication was thrown than 
> this is translated to an HTTP 403 status code.
> But this Http status code is not send as response. This sends a 200 status 
> code. After a time of debugging i found the code that is responsible for 
> that. The processResponse method of the 
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor work not correct is 
> guess. Because code with the following code block this methods ends.
> OperationResourceInfo operation = 
> (OperationResourceInfo)exchange.get(OperationResourceInfo.class
>             .getName());
>         if (operation == null) {
>             return;
>         }
> because the operation variable is null. The code after this is responsible to 
> but the Response from the ExceptionMapper class into the message object so 
> that i received a 403 http status code.
> I've searched the code again and i found the code block how put the 
> OperationResourceInfo into the Exchange object. That is done by the 
> processRequest method of the 
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor class. But before the 
> OperationResourceInfo object is putted in the registered ResourceHandler are 
> called see the code block below.
>  for (ProviderInfo<RequestHandler> sh : shs) {
>             Response response = sh.getProvider().handleRequest(message, 
> resource);
>             if (response != null) {
>                 message.getExchange().put(Response.class, response);
>                 return;
>             }
>         }
> I guess the code how put in the OperationresourceInfo object could be 
> performed before the RequestHandlers are called maybe? 
> Or it's forbidden to throw a Runtimeexception inside the RequestHandler ?
> I've also tried to return an Response object from the RequestHandler but the 
> effect was the same it never arrives the client. It received also the 
> Response object with http code 200.
> The CXF framework is great and very flexible good work. The opportunities to 
> register own code is very great.
> Good work.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to