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

Andreas Veithen commented on CXF-2709:
--------------------------------------

This can already be achieved with the current API, at least partially. The 
pattern is to use a feature (in the sense of 
org.apache.cxf.feature.AbstractFeature) that inserts a proxy in front of the 
invoker. [1] provides an example. This approach is known to work well with 
JAX-RS and JAX-WS.

[1] 
http://svn.apache.org/repos/asf/cxf/sandbox/veithen/cxf-spring-security/cxf-spring-security/src/main/java/org/apache/cxf/security/spring/SpringSecurityContextFeature.java

> Provide Method Invocation Interceptor
> -------------------------------------
>
>                 Key: CXF-2709
>                 URL: https://issues.apache.org/jira/browse/CXF-2709
>             Project: CXF
>          Issue Type: New Feature
>          Components: Configuration, Core, JAX-RS, JAX-WS Runtime
>    Affects Versions: 2.2.5
>         Environment: JAX-RS, JAX-WS
>            Reporter: Stephen Todd
>
> It would be helpful if there was some kind of MethodInvocationInterceptor (or 
> alternatively with In/Out variants) that could be applied against Invokers 
> before they do the actual method call for jax-rs and jax-ws. I'm thinking the 
> place that the interceptor would be called is in 
> AbstractInvoker.performInvocation() around m.invoke().
> What this provides for is the ability to perform some action or filtering 
> based on information from the java.lang.Method, parameter and return  values 
> before or after the invocation is actually made.
> Two cases that I am looking at are to be able to check for annotations on a 
> method and do some processing for security, transaction management, and/or 
> validation. Currently, the only way to be able to perform logic on custom 
> annotations is to create proxies around singleton beans or something like 
> aspectj. By allowing for these kind of interceptors, this would no longer be 
> necessary.
> These interceptors make it simple to do things such as check for 
> spring-security @Pre/PostAuthorize annotations and apply security 
> constraints. Likewise, I'm also wanting to implement JSR-303 validation 
> checking against method parameters like is done for spring @Controller 
> classes. This would keep cxf's jaxrs implementation on par with spring's rest 
> framework. Adding @Transactional logic would also be possible through this.
> In jax-rs, not having this creates difficulty providing this logic since 
> using singletons imposes the requirement that the resources be stateless. The 
> java changes would be simple, though it would also need some work done in 
> spring configuration code as well.

-- 
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