1:54 p.m.
My use case is that I want an Auth interceptor which would support both
BASIC and Bearer Token authentication depending on the app's
configuration. My config information is accessible via a
@ApplicationScoped client service (ConfigurationService). I would like
to inject that into my interceptor. Currently the interceptors are
simply new'd up when needed.
I think we need to make interceptor creation asynchronous so that the
async bean manager in IOC can be (optionally) used. Attached to this
email are there files:
samplecode.txt - code generated now (e.g. JaxrsProxyLoaderImpl.java)
samplecode-async.txt - suggestion for how to make it async
samplecode-ioc.txt - optional code generation iff the IOC module is present
Thoughts?
I could take a stab at this if it seems reasonable, but I don't want to
start down this road if anyone can spot a glaring problem.
Also notice that I removed the return value for proceed() as I do not
believe it is required/used.
-Eric
5:07 p.m.
Hi,
Just summarizing from our discussions on IRC:
Yes, this is what it would take to make this work. I also like your AsyncBeanFactory
approach because it simplifies the generated code.
To decide what code to generate at rebind time (new vs. bean manager lookup) you can use
RebindUtils.getInheritedModules() to check if Errai IOC is available.
As an immediate solution (workaround that doesn't require any change), you can lookup
beans within interceptor implementations using IOC.getBeanManager().lookupBean().
Cheers,
Christian
On 2014-02-11, at 1:54 PM, Eric Wittmann <eric.wittmann(a)redhat.com> wrote:
My use case is that I want an Auth interceptor which would support
both BASIC and Bearer Token authentication depending on the app's configuration. My
config information is accessible via a @ApplicationScoped client service
(ConfigurationService). I would like to inject that into my interceptor. Currently the
interceptors are simply new'd up when needed.
I think we need to make interceptor creation asynchronous so that the async bean manager
in IOC can be (optionally) used. Attached to this email are there files:
samplecode.txt - code generated now (e.g. JaxrsProxyLoaderImpl.java)
samplecode-async.txt - suggestion for how to make it async
samplecode-ioc.txt - optional code generation iff the IOC module is present
Thoughts?
I could take a stab at this if it seems reasonable, but I don't want to start down
this road if anyone can spot a glaring problem.
Also notice that I removed the return value for proceed() as I do not believe it is
required/used.
-Eric
<samplecode-async.txt><samplecode-ioc.txt><samplecode.txt>_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev
8:09 a.m.
I can start working on this today if you don't see any problems with the
approach.
Note: this change would result in CreationalCallback being moved from
errai-ioc to errai-common so it can be re-used.
I would like to point out that the workaround is only valid if the bean
manager is synchronous. If the bean manager is actually async then I
think the workaround will fail. The reason is that the interceptor is
currently called like this:
new CustomInterceptor().aroundInvoke(this);
I currently have my authentication interceptor looking up my
configuration service in its constructor. However, I'm getting the sync
bean manager back, so this is ok. If I got the async bean manager back
then I think the c'tor would return immediately, then aroundInvoke()
would get called, then the bean would get looked up from the bean
manager. The result would probably be an NPE in my aroundInvoke() when
I tried to use the service.
So I think it's important to make the interceptor chain async asap (ha!).
-Eric
On 2/11/2014 5:07 PM, Christian Sadilek wrote:
Hi,
Just summarizing from our discussions on IRC:
Yes, this is what it would take to make this work. I also like your AsyncBeanFactory
approach because it simplifies the generated code.
To decide what code to generate at rebind time (new vs. bean manager lookup) you can use
RebindUtils.getInheritedModules() to check if Errai IOC is available.
As an immediate solution (workaround that doesn't require any change), you can lookup
beans within interceptor implementations using IOC.getBeanManager().lookupBean().
Cheers,
Christian
On 2014-02-11, at 1:54 PM, Eric Wittmann <eric.wittmann(a)redhat.com> wrote:
> My use case is that I want an Auth interceptor which would support both BASIC and
Bearer Token authentication depending on the app's configuration. My config
information is accessible via a @ApplicationScoped client service (ConfigurationService).
I would like to inject that into my interceptor. Currently the interceptors are simply
new'd up when needed.
>
> I think we need to make interceptor creation asynchronous so that the async bean
manager in IOC can be (optionally) used. Attached to this email are there files:
>
> samplecode.txt - code generated now (e.g. JaxrsProxyLoaderImpl.java)
> samplecode-async.txt - suggestion for how to make it async
> samplecode-ioc.txt - optional code generation iff the IOC module is present
>
> Thoughts?
>
> I could take a stab at this if it seems reasonable, but I don't want to start
down this road if anyone can spot a glaring problem.
>
> Also notice that I removed the return value for proceed() as I do not believe it is
required/used.
>
> -Eric
>
<samplecode-async.txt><samplecode-ioc.txt><samplecode.txt>_______________________________________________
> errai-dev mailing list
> errai-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-dev
_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev
3724
days inactive
3725
days old
2 comments
2 participants
participants (2)
-
Christian Sadilek -
Eric Wittmann