cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Todd (JIRA)" <>
Subject [jira] Commented: (CXF-2709) Provide Method Invocation Interceptor
Date Sat, 13 Mar 2010 01:13:27 GMT


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

View raw message