<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 19, 2017 at 1:59 PM, Martin Kouba <span dir="ltr"><<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
</span></blockquote>
<br>
No really. Weld stores the bindings also in context data but the API is using a direct reference to a stored set.</blockquote><div><br></div><div>Ah, ok, thx</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Going via getContextData() is much easier though for code that has to support both Weld and OWB.<br>
</blockquote>
<br></span>
Yep, standardizing the key is the only viable solution without interceptors spec change. However, it's not typesafe, easy-to-use, etc.</blockquote><div><br></div><div>I hear you. The question is when the earliest opportunity will be to update the interceptor spec then. With the whole Java EE transfer I guess this will have to wait at least until that transfer is complete. Hopefully in the new process we can have something like a hierarchical responsibility for specs, such that if e.g. Interceptors and AtInject is not explicitly open, but CDI is, that the CDI EG can take responsibility for it and make changes there.</div><div><br></div><div>For now though, if OWB could also store the bindings under some key, interceptors that are intended to be portable can practically check both keys then. Not ideal, but may be a good intermediate solution.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">And this is obviously wrong. Recently, we've reviewed a Narayana PR which is about to fix this problem:<br>
<a href="https://github.com/jbosstm/narayana/pull/1211" rel="noreferrer" target="_blank">https://github.com/jbosstm/nar<wbr>ayana/pull/1211</a><br>
<br>
I personally think that JTA TCK is missing some essential tests here.</blockquote><div><br></div><div>Agreed, and the Java EE Security TCK misses those same tests as well, as it also ships with interceptors.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I don't think this is an InterceptionFactory-specific problem. It's a general issue. It should work the same if you use an extension to add an interceptor binding.<br></blockquote><div><br></div><div><br></div><div>You're right, the InterceptionFactory just brought it to the surface again for people testing CDI 2.0 features.</div><div><br></div><div>Handling stereotypes as per the issue can be a problem as well. I wonder, wouldn't it be convenient if CDI offers a utility method to look for an annotation where it would automatically recurses into stereotypes?</div><div><br></div><div>I created something like for OmniFaces a while ago:</div><div><br></div><div><a href="https://github.com/omnifaces/omnifaces/blob/develop/src/main/java/org/omnifaces/util/BeansLocal.java#L221">https://github.com/omnifaces/omnifaces/blob/develop/src/main/java/org/omnifaces/util/BeansLocal.java#L221</a><br></div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
<br>
<br>
<br>
Is there a standard way to get the bindings? Perhaps getting<br>
hold of the Bean<T> that represents the current Interceptor?<br>
<br>
<br>
You can inject a bean with scope @Dependent, qualifier @Default and<br>
type Interceptor into any interceptor instance. However, this will<br>
not help for @Nonbinding value members of an interceptor binding.<br>
<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
______________________________<wbr>_________________<br>
cdi-dev mailing list<br></span>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.or<wbr>g</a>><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/cdi-dev</a><span class="gmail-"><br>
<<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailm<wbr>an/listinfo/cdi-dev</a>><br>
<br>
Note that for all code provided on this list, the provider<br>
licenses the code under the Apache License, Version 2<br>
(<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/license<wbr>s/LICENSE-2.0.html</a><br></span>
<<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/license<wbr>s/LICENSE-2.0.html</a>>). For all<span class="gmail-"><br>
other ideas provided on this list, the provider waives all<br>
patent and other intellectual property rights inherent in such<br>
information.<br>
<br>
<br>
-- Martin Kouba<br>
Senior Software Engineer<br>
Red Hat, Czech Republic<br>
<br>
<br>
</span></blockquote><div class="gmail-HOEnZb"><div class="gmail-h5">
<br>
-- <br>
Martin Kouba<br>
Senior Software Engineer<br>
Red Hat, Czech Republic<br>
</div></div></blockquote></div><br></div></div>