|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
_______________________________________________ weld-issues mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-issues
I think I understand that invoking proceed() in the interceptor works.
I've opened this ticket to show you instead in the simplest possible "test terms" that delegating the invocation to a scoped bean fails. The need to delegate is genuine for me, and I'd rather not 'avoid it'. To be clear, in my real code base, I wrap the invocation in a Callable and send it away to an engine of sorts that dispatches it further around and finally executes it. Seems a very reasonable use of interceptors to me, especially because the final invocation occurs in the original call stack (no multi-threading, as in my example).
So, my question is: is delegation to a scope bean prevented for a reason? If so, is it documented (could not find evidence anywhere)? I suspect it isn't, as it does work fine with unscoped beans (dependent, singletons). I suspect instead there may be some mis-interaction between the interception mechanisms and the scope-proxying mechanisms, some loss of context that makes the proxy believe the intercepting chain ought to be called again from the beginning. thanks.