[seam-dev] Interceptor packaging convention

[Lincoln Baxter, III]

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.

95% of the time that is going to be enough. 5% of the time it's not.

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?

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.

This is a matter of usability, and being developer-centric:

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.

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?"

I think the enabler JAR is a good way to hide complexity, while still
allowing for technical correctness *if required.*

--Lincoln

On Mon, Mar 29, 2010 at 2:32 PM, Gavin King <gavin.king at gmail.com> wrote:

> 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
>



-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100329/b799c677/attachment-0001.html