I understand the technical reasons why interceptor ordering is important, but I disagree completely with the lack of options, or ability to ignore said technical reasons. The reason the enabler jar works well is because it provides a consistent way to order interceptors *within* the Seam framework.<br>
<br>95% of the time that is going to be enough. 5% of the time it's not.<br><br>Why should we force people to work extra hard to get things working, when they should only have to work extra hard if there is a problem? Think of it from the POV of a user: Do they want to fix things to get started? Or do they want to fix things only if they are broken?<br>
<br>This isn't a matter of technical correctness, we can ensure technical correctness by allowing users to exclude the Seam-enabler.jar from their POM and fall back to Beans.xml for manual interceptor registration.<br>
<br>This is a matter of usability, and being developer-centric:<br><br>Technical constraints cannot enforce social practices (as CDI is doing by preventing automatic interceptor registration), so it's best to try not to -- this is the perfect example. We have several people who are already willing to violate best practices of "Designing to the Interface," by referencing the implementation specifics, to get this working. If CDI provided a standard "incorrect" way of doing it, we could do things "the bad way" without breaking any more rules.<br>
<br>It doesn't matter how much technical thought went into it -- if CDIs consumers want to do something, they'll figure out how to do it anyway -- the question is purely, "how annoyed do we want them to feel at the end of the day?"<br>
<br>I think the enabler JAR is a good way to hide complexity, while still allowing for technical correctness <b>if required.</b><br><br>--Lincoln<br><br><div class="gmail_quote">On Mon, Mar 29, 2010 at 2:32 PM, Gavin King <span dir="ltr"><<a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This topic was already discussed here:<br>
<br>
<a href="http://relation.to/Bloggers/OnCDIInterceptorBindings" target="_blank">http://relation.to/Bloggers/OnCDIInterceptorBindings</a><br>
<br>
and here:<br>
<br>
<a href="http://www.seamframework.org/Community/EnablingAnInterceptorInALibrary" target="_blank">http://www.seamframework.org/Community/EnablingAnInterceptorInALibrary</a><br>
<br>
so far no-one has proposed any solution that allows auto-registration<br>
and avoids the multiple-portable-extension clusterfuck.<br>
<br>
Trust me, this stuff was *very* carefully thought out by the expert<br>
group. It is the way it is for very good reasons.<br>
<div><div></div><div class="h5"><br>
On Mon, Mar 29, 2010 at 2:10 PM, Lincoln Baxter, III<br>
<<a href="mailto:lincolnbaxter@gmail.com">lincolnbaxter@gmail.com</a>> wrote:<br>
> It depends -- each module could have a number of interceptors. You'd turn<br>
> the interceptors off by excluding the global enabler dependency that Dan<br>
> described, or re-including it as <provided> - whichever you see fit.<br>
><br>
> Perhaps yet another option would be to separate auto-registered interceptors<br>
> into their own maven sub-modules, if we REALLY need to be that specific.<br>
> This way you could include to enable each interceptor manually:<br>
><br>
> seam-faces<br>
> seam-faces-conversations<br>
> seam-faces-security<br>
><br>
> But again, and I am going to stand by this vehemently: I want automatic<br>
> registration of interceptors. Provide what users want 95% of the time, and<br>
> allow them to become more granular ONLY if they are in that 5% case -- but<br>
> don't require every user to understand the ugly, complicated 5%. That's how<br>
> Java EE, JSF, EJB, SOAP, etc, all lost their reputations.<br>
><br>
> Developer experience is crucial when designing this kind of interaction in a<br>
> framework. These things will be the difference between adoption and<br>
> abandonment.<br>
><br>
> --Lincoln<br>
><br>
> On Mon, Mar 29, 2010 at 2:03 PM, Nicklas Karlsson <<a href="mailto:nickarls@gmail.com">nickarls@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Tools might also be helpful in setting up interceptors based on what you<br>
>> have available, I suppose. And the list of interceptors for a normal Seam 3<br>
>> application is hopefully shorter than that from a Seam 2 app.<br>
>><br>
>> On Mon, Mar 29, 2010 at 7:30 PM, Gavin King <<a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>> wrote:<br>
>>><br>
>>> I think you guys have got this wrong. CDI was deliberately designed to<br>
>>> require explicit declaration of interceptors. We thought VERY HARD<br>
>>> about this, and realized that this was the best way to go. Any<br>
>>> auto-registration of interceptors runs into all kinds of problems down<br>
>>> the road:<br>
>>><br>
>>> (1) When I use two frameworks together, or add my own interceptor to<br>
>>> the interceptors defined by a framework, what is its ordering with<br>
>>> respect to the interceptors that already exist?<br>
>>><br>
>>> (2) How do I turn an interceptor off?<br>
>>><br>
>>> Look, CDI is supposed to be an ecosystem for multiple portable<br>
>>> extensions that play nicely together. Auto-enablement of interceptors<br>
>>> gets you into the total clusterfuck of phase listeners in JSF.<br>
>>><br>
>>> Don't go down this path.<br>
>>><br>
>>> --<br>
>>> Gavin King<br>
>>> <a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a><br>
>>> <a href="http://in.relation.to/Bloggers/Gavin" target="_blank">http://in.relation.to/Bloggers/Gavin</a><br>
>>> <a href="http://hibernate.org" target="_blank">http://hibernate.org</a><br>
>>> <a href="http://seamframework.org" target="_blank">http://seamframework.org</a><br>
>>> _______________________________________________<br>
>>> seam-dev mailing list<br>
>>> <a href="mailto:seam-dev@lists.jboss.org">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>
>><br>
>><br>
>><br>
>> --<br>
>> ---<br>
>> Nik<br>
><br>
><br>
><br>
> --<br>
> Lincoln Baxter, III<br>
> <a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br>
> <a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>
> "Keep it Simple"<br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class="h5">Gavin King<br>
<a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a><br>
<a href="http://in.relation.to/Bloggers/Gavin" target="_blank">http://in.relation.to/Bloggers/Gavin</a><br>
<a href="http://hibernate.org" target="_blank">http://hibernate.org</a><br>
<a href="http://seamframework.org" target="_blank">http://seamframework.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com">http://ocpsoft.com</a><br><a href="http://scrumshark.com">http://scrumshark.com</a><br>"Keep it Simple"<br>