OK I have a pull request for this. I ended up with a separate proposed
implementation that was much easier to execute. Namely there is a new
annotation @InterceptsRemoteCall that references the interfaces that
should be intercepted. This annotation is applied to the interceptor
class itself. So something like this:
@InterceptsRemoteCall({ RemoteOne.class, RemoteTwo.class })
public class MyInterceptor implements RestClientInterceptor {
@Override
public void aroundInvoke(RestCallContext context) {
context.getRequestBuilder()
.setHeader("X-Custom-Header", "Custom Value");
context.proceed(); // must be called to continue chain
}
}
This solves the core problem of being able to intercept calls to remote
interfaces without modifying (annotating) those interfaces.
Pull request: https://github.com/errai/errai/pull/80
The PR does *not* include any Interceptor + IOC enhancements. I have a
proposal for that and will email it out separately.
-Eric
On 2/9/2014 7:03 PM, Christian Sadilek wrote:
> Yes, I think this is what it should look like. However, we have to make sure
> errai-bus and errai-jaxrs (both support client-side interceptors) can be used
> without errai-ioc. We have people in the community using these modules with
> alternative IOC providers (GIN).
>
> This is something we have to consider when implementing this especially in
> regards to interceptor instances being managed beans. We now have a way to
> determine (at rebind time) whether or not errai-ioc was inherited. So, we
> could generate different code if that's the case.
>
> Cheers,
> Christian
>
> On 2014-02-07, at 3:11 PM, Eric Wittmann <[email protected]> wrote:
>
>> I think I'm a fan of option #2. To be clear, would it look like this (for
>> example)?
>>
>> @Templated
>> @Page(path="dashboard", role=DefaultPage.class)
>> @Dependent
>> public class DashboardPage extends AbstractPage {
>>
>> @Inject
>> @Interceptors({ AuthInterceptor.class, ReqHeaderInterceptor.class })
>> private Caller<IMyRestService> caller;
>>
>> }
>>
>> That seems pretty slick to me. It does mean that if I inject that Caller in
>> multiple places I need to specify the interceptor list each time. But that
>> actually sounds pretty powerful to me.
>>
>> Would the interceptors be managed beans (i.e. injected into the Caller)? My
>> use case would be that I'd have an AuthenticationInterceptor for my Caller,
>> but I would want to @Inject a configuration bean of some kind into it,
>> because I might be using either BASIC auth *or* Bearer Token auth, and the
>> managed configuration bean is what knows which it is.
>>
>> -Eric
>>
>> PS: adding the errai-dev list to the conversation, which is what I should
>> have done originally
>>
>> On 2/7/2014 11:35 AM, Christian Sadilek wrote:
>>> Yeah, I had thought about that as well before but couldn't decide what's
>>> best:
>>>
>>> - Add a mapping to ErraiApp.properties
>>> - Add an annotation/qualifier @Interceptors(...) that can be used when
>>> injecting a Caller<?>
>>> - Add a parameter to call() that takes a List of interceptors
>>>
>>> Definitely a good feature to have. Wdyt?
>>>
>>> Cheers,
>>> Christian
>>>
>>> On 2014-02-07, at 10:06 AM, Eric Wittmann <[email protected]> wrote:
>>>
>>>> I was reading the documentation re: client interceptors for jax-rs in
>>>> Errai and I was wondering what you thought about adding a mechanism to
>>>> allow client interceptors to be defined either globally or in some way
>>>> that doesn't require modifying the JAX-RS interface (to add annotations).
>>>> I'm thinking that in some cases a developer might be creating a UI and
>>>> invoking REST services where they have access to the jax-rs interfaces but
>>>> do not have write privs. In other words they can consume them but not
>>>> modify them. In that case it might be nice to able to apply interceptors
>>>> in some other way.
>>>>
>>>> Thoughts?
>>>>
>>>> -Eric
>>>
>
_______________________________________________
errai-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/errai-dev
