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:


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@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@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.
_______________________________________________
seam-dev mailing list
seam-dev@lists.jboss.org



--
---
Nik



--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"