You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Stephen Todd (JIRA)" <ji...@apache.org> on 2010/03/12 02:45:27 UTC
[jira] Created: (CXF-2709) Provide Method Invocation Interceptor
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.
[jira] Commented: (CXF-2709) Provide Method Invocation Interceptor
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845142#action_12845142 ]
Sergey Beryozkin commented on CXF-2709:
---------------------------------------
Hi Stephen
First, extending JAXRSInvoker would give you a chance to intercept sub resource invocations too,
just extend
public Object invoke(Exchange exchange, Object request, Object resourceObject) {
}
You will get this method invoked for the root resource and then for every subsequent sub resource invocation (provided you delegate to the super class after validating/etc)
please see
http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/JAXRSInvoker.java
for more info.
> Now I wouldn't implement it that way, I would probably create my own interceptor interface and execute those in my own custom implementation of (JAXRS|JAXWS)Invoker.
sounds reasonable...
> When working with interfaces, I can be reasonably assured that updates wont break my code.
I see your concern. I really do not plan on changing the signature of
invoke(Exchange exchange, Object request, Object resourceObject)
That said I was planning to add so called invocation RequestHandlers, they will execute before every invocation (on root and all the subresources) as opposed to 'regular' RequestHandlers which execute only once before a root resource is invoked.
Introducing per-method specific filters seems interesting; I agree with Andreas you can do what you need using existing api but I'll think what else can be done, may take a bit of time.
Sergey
cheers, Sergey
> 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.
[jira] Commented: (CXF-2709) Provide Method Invocation Interceptor
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844711#action_12844711 ]
Daniel Kulp commented on CXF-2709:
----------------------------------
I'm not sure about JAX-RS, but for JAX-WS, the way we enable this is to allow the user to configure in their own Invoker. Normally, in your case, you would subclass the JAXWSMethodInvoker or similar to do whatever custom stuff you need done. The jaxws:endpoint entry allows specifying your invoker to use.
> 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.
[jira] Commented: (CXF-2709) Provide Method Invocation Interceptor
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CXF-2709) Provide Method Invocation Interceptor
Posted by "Stephen Todd (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844691#action_12844691 ]
Stephen Todd commented on CXF-2709:
-----------------------------------
Andreas, thanks for your response. Unfortunately, this wont work since the interface for Invoker is only:
public interface Invoker {
Object invoke(Exchange exchange, Object o);
}
which doesn't provide you the Method that will actually be called, and in the case of JAX-RS, it is only called once. JAXRSInvoker does, however, delegate to AbstractInvoker.invoke(Exchange, Object, Method, List<Object>), which is called on each resource as it proceeds through the resources.
So if I have:
@Path("")
class Resource {
@Path("subresource")
@PreAuthorize("hasRole('SUB_RESOURCE_ACCESS')")
SubResource getSubResource() {...}
}
@Path("")
class SubResource {
@GET
@Path("foo")
@PreAuthorize("hasRole('FOO_READ')")
String getFoo() {...}
}
There is nowhere, in JAS-RS at least, for me to be able to capture either call to Resource.getSubResource() and SubResource.getFoo() when a user accesses /subresource/foo. I can only capture that the service is called without knowing exactly which method it is going to resolve to.
Even further, AbstractInvoker.invoke(Exchange, Object, Method, List<Object>) doesn't necessarily have the full parameter list since the Exchange can get added later. The only place where the entire Method is found with all its parameters is inside AbstractInvoker.performInvocation().
Maybe I'm the only one really using sub-resources jax-rs, but I think this would be pretty helpful.
> 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.
[jira] Commented: (CXF-2709) Provide Method Invocation Interceptor
Posted by "Stephen Todd (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844787#action_12844787 ]
Stephen Todd commented on CXF-2709:
-----------------------------------
JAX-RS lets you configure your own invoker, but architecturally, enhancement through subclassing is pretty brittle. For example, any time you want to add in additional capability, you have to extend the class. If it's just one enhancement, then it's not as big a problem, but if I want to make multiple enhancements, I have to put each one in the class hierarchy or all together in one class (not too good for reusability). So my class hierarchy would look like: AbstractInvoker > JAXRSInvoker > TransactionalJAXRSInvoker > ValidatingTransactionalJAXRSInvoker > etc. Now I wouldn't implement it that way, I would probably create my own interceptor interface and execute those in my own custom implementation of (JAXRS|JAXWS)Invoker.
But even creating my own version of the Invoker I can get in trouble since I'm not working on interfaces. When working with interfaces, I can be reasonably assured that updates wont break my code. But if I extend and I override protected methods (which I would have to do to make this work), I don't have that assurance. Beyond that, extension requires me to be very familiar with the code in order to provide the enhancement.
> 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.