2:11 p.m.
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 <eric.wittmann(a)redhat.com> 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
6:03 p.m.
New subject: Client interceptors - jax-rs
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 <eric.wittmann(a)redhat.com> 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 <eric.wittmann(a)redhat.com> 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
>
6:29 a.m.
New subject: Client interceptors - jax-rs
Ok that sound fine. If you point me at how to determine if errai-ioc is
inherited, I'd be willing to take a stab at implementing this.
-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 <eric.wittmann(a)redhat.com> 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 <eric.wittmann(a)redhat.com>
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
>>
12:27 p.m.
New subject: Client interceptors - jax-rs
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 <eric.wittmann(a)redhat.com> 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 <eric.wittmann(a)redhat.com>
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
>>
3941
days inactive
3945
days old
3 comments
2 participants
participants (2)
-
Christian Sadilek -
Eric Wittmann