[seam-dev] Interceptor packaging convention

[Gavin King]

This topic was already discussed here:

  http://relation.to/Bloggers/OnCDIInterceptorBindings

and here:

  http://www.seamframework.org/Community/EnablingAnInterceptorInALibrary

so far no-one has proposed any solution that allows auto-registration
and avoids the multiple-portable-extension clusterfuck.

Trust me, this stuff was *very* carefully thought out by the expert
group. It is the way it is for very good reasons.

On Mon, Mar 29, 2010 at 2:10 PM, Lincoln Baxter, III
<lincolnbaxter at gmail.com> wrote:
> It depends -- each module could have a number of interceptors. You'd turn
> the interceptors off by excluding the global enabler dependency that Dan
> described, or re-including it as <provided> - whichever you see fit.
>
> Perhaps yet another option would be to separate auto-registered interceptors
> into their own maven sub-modules, if we REALLY need to be that specific.
> This way you could include to enable each interceptor manually:
>
> seam-faces
> seam-faces-conversations
> seam-faces-security
>
> But again, and I am going to stand by this vehemently: I want automatic
> registration of interceptors. Provide what users want 95% of the time, and
> allow them to become more granular ONLY if they are in that 5% case -- but
> don't require every user to understand the ugly, complicated 5%. That's how
> Java EE, JSF, EJB, SOAP, etc, all lost their reputations.
>
> Developer experience is crucial when designing this kind of interaction in a
> framework. These things will be the difference between adoption and
> abandonment.
>
> --Lincoln
>
> On Mon, Mar 29, 2010 at 2:03 PM, Nicklas Karlsson <nickarls at gmail.com>
> wrote:
>>
>> Tools might also be helpful in setting up interceptors based on what you
>> have available, I suppose. And the list of interceptors for a normal Seam 3
>> application is hopefully shorter than that from a Seam 2 app.
>>
>> On Mon, Mar 29, 2010 at 7:30 PM, Gavin King <gavin.king at gmail.com> wrote:
>>>
>>> I think you guys have got this wrong. CDI was deliberately designed to
>>> require explicit declaration of interceptors. We thought VERY HARD
>>> about this, and realized that this was the best way to go. Any
>>> auto-registration of interceptors runs into all kinds of problems down
>>> the road:
>>>
>>> (1) When I use two frameworks together, or add my own interceptor to
>>> the interceptors defined by a framework, what is its ordering with
>>> respect to the interceptors that already exist?
>>>
>>> (2) How do I turn an interceptor off?
>>>
>>> Look, CDI is supposed to be an ecosystem for multiple portable
>>> extensions that play nicely together. Auto-enablement of interceptors
>>> gets you into the total clusterfuck of phase listeners in JSF.
>>>
>>> Don't go down this path.
>>>
>>> --
>>> Gavin King
>>> gavin.king at gmail.com
>>> http://in.relation.to/Bloggers/Gavin
>>> http://hibernate.org
>>> http://seamframework.org
>>> _______________________________________________
>>> seam-dev mailing list
>>> seam-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>>
>> --
>> ---
>> Nik
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org