<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">>><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td valign="top" style="font:inherit">
Especially the last sentence definitely makes clear that Lincolns use case should 'just work'. I think this is only a bug in Weld being overly strict and not in the spec (this works in OWB btw). <br><br></td></tr>
</tbody></table></blockquote><div><br></div><div>And that should be checked against trunk since I made some changes there and the stack trace origins from a place that no longer exists... </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td valign="top" style="font:inherit">b) such a enabler.jar would not work imo in a modular environment, because "If there is no class with the specified name, or if the class with the specified name is not an interceptor
class, the container automatically detects the problem and treats it as a deployment problem." So if one jar is not in the dependencies, the list must not contain the Interceptors from this jar.<br><br></td></tr></tbody></table>
</blockquote><div><br></div><div>I don't think that's an issue since we would only enable stuff already known to the bean manager. In fact, it would be safer than enablement through beans.xml, not?</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><table cellspacing="0" cellpadding="0" border="0"><tbody><tr><td valign="top" style="font:inherit">LieGrue,<br>strub<br>
<br>--- Nicklas Karlsson <i><<a href="mailto:nickarls@gmail.com" target="_blank">nickarls@gmail.com</a>></i> schrieb am <b>Sa, 27.3.2010:<br></b><blockquote style="border-left:2px solid rgb(16, 16, 255);margin-left:5px;padding-left:5px">
<b><br>Von: Nicklas Karlsson <<a href="mailto:nickarls@gmail.com" target="_blank">nickarls@gmail.com</a>><br>Betreff: Re: [seam-dev] Interceptor packaging convention<br>An: "Dan Allen" <<a href="mailto:dan.j.allen@gmail.com" target="_blank">dan.j.allen@gmail.com</a>><br>
CC: "Seam Dev List" <<a href="mailto:seam-dev@lists.jboss.org" target="_blank">seam-dev@lists.jboss.org</a>><br>Datum: Samstag, 27. März, 2010 08:28 Uhr<br><br></b><div><div></div><div class="h5"><div><b>I think AfterBeanDiscovery is enough (which is already in the spec) for the autoenablement extension, right?</b><div>
<b><br></b></div><div><b>We could cast the BeanManager parameter to BeanManagerImpl and enable (and perhaps sort) all org.seam.*
interceptors etc that the BM is aware of. Since there is a limited number of CDI implementations, we could also cast to other implementations after checking (non-imported, reflection) which one we are dealing with.</b></div>
<div><b><br></b></div><div><b>We could also throw in a</b></div><div><b><br></b></div><div><b>@AutoEnable(before="org.jboss.seam.foo.Interceptor") </b></div><div><b><br></b></div><div><b>annotation if want to control the order manually or if we want to offer others to use this feature (in a seam context)</b></div>
<div><b><br><br></b><div class="gmail_quote"><b>On Fri, Mar 26, 2010 at 7:35 PM, Dan Allen <span dir="ltr"><<a rel="nofollow" href="http://mc/compose?to=dan.j.allen@gmail.com" target="_blank">dan.j.allen@gmail.com</a>></span> wrote:<br>
</b><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div class="gmail_quote"><div><b>On Fri, Mar 26, 2010 at 1:28 PM, Dan Allen <span dir="ltr"><<a rel="nofollow" href="http://mc/compose?to=dan.j.allen@gmail.com" target="_blank">dan.j.allen@gmail.com</a>></span> wrote:<br>
</b><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div class="gmail_quote"><div><b><br></b></div><div><div><b>On Thu, Mar 25, 2010 at 11:25 PM, Nicklas Karlsson <<a rel="nofollow" href="http://mc/compose?to=nickarls@gmail.com" target="_blank">nickarls@gmail.com</a>> wrote:</b></div>
</div><div><div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0px 0px 0px 0.8ex;padding-left:1ex">
<b>Perhaps I'm missing something here but can't the ProcessModule event from 11.5.5 fix this with List<Class> getInterceptors()?</b></blockquote></div><div><b><br></b></div></div><div><b>Two things. First, the ProcessModule did not make CDI 1.0, but was added later. I'm not sure if the version containing it has been "released" or approved. Second, that only gets you the interceptors. Lincoln and I were tricked by that a couple of times...what we need is to modify the <i>enabled</i> interceptors. That's where we keep getting bitten.</b></div>
</div></blockquote><div><b><br></b></div></div><div><b>Oops! I was wrong. It does give you read/write access to the enabled interceptors. Okay, so this would be a possibility to either add interceptors or warn the developer to add them. But this listener would have to still know about any and all interceptors that need to be enabled (if the modules beans.xml is empty as we want it to be).</b></div>
<div><b><br></b></div><div><b>So we could provide a seam-interceptor-enabler.jar that would enable any Seam interceptors on the classpath. We would only provide one such JAR file. This is the right way to go. It only requires that we depend on the latest version of the spec, which Weld doesn't yet support fully (not ProcessModule at least).</b></div>
<div><b><br></b></div><div><b>Therefore, we have two possible ways forward. The developer lists out the interceptors or we provide an enabler JAR. But remember, observer call order is not portable, so if you have another enabler JAR from another extension library, then how to order them gets tricky. The enabler really needs to be a closed system.</b></div>
<div><b><br></b></div><b><font color="#888888"><div>-Dan</div><div><br></div></font></b></div><div><div></div><div><b>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br>
<br><a rel="nofollow" href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br>
<a rel="nofollow" href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br><a rel="nofollow" href="http://www.google.com/profiles/dan.j.allen" target="_blank">http://www.google.com/profiles/dan.j.allen</a><br>
</b></div></div><b><br>_______________________________________________<br>
seam-dev mailing list<br>
<a rel="nofollow" href="http://mc/compose?to=seam-dev@lists.jboss.org" target="_blank">seam-dev@lists.jboss.org</a><br>
<a rel="nofollow" href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
<br></b></blockquote></div><b><br><br clear="all"><br>-- <br>---<br>Nik<br>
</b></div>
</div></div></div><b><br>-----Integrierter Anhang folgt-----<br><br></b><div class="im"><div><b>_______________________________________________<br>seam-dev mailing list<br><a href="http://mc/compose?to=seam-dev@lists.jboss.org" target="_blank">seam-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br></b></div></div></blockquote></td></tr></tbody></table><br><div><div></div><div class="h5">
__________________________________________________<br>Do You Yahoo!?<br>Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. <br><a href="http://mail.yahoo.com" target="_blank">http://mail.yahoo.com</a> </div>
</div></blockquote></div><br><br clear="all"><br>-- <br>---<br>Nik<br>