>From the POV of a professional Seam 2.x user (and potential Weld/Seam 3 user) I'd like to state that one of the things I like about Seam is the mostly static and minimal (e.g. components.xml, pages.xml, web.xml and faces-config.xml) XML files I need to touch.  Focusing on ease-of-use is critical to adoption.

Regarding this particular argument, I'm going to side with GKing.  Realistically, as a user of this frmwk, how many times per day/week, on average, would I have to update the beans.xml file for a large-sized project (i.e. multi-module Mavenized Seam project)?  I don't touch the above mentioned Seam 2.x xml files every day or sometimes even every week/month (thanks to annotations).

And it is possible that we will write and use custom interceptors from time-to-time.  So in this more complicated scenario (multiple portable extensions, etc.) how shall we avoid the "clusterfuck" that GKing envisions if we don't do it his (the spec's) way??

How much of an inconvenience is it to the dev on a daily basis??

On Mon, Mar 29, 2010 at 11:56 AM, Gavin King <gavin.king@gmail.com> wrote:
On Mon, Mar 29, 2010 at 2:47 PM, Lincoln Baxter, III
<lincolnbaxter@gmail.com> wrote:
> 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.

I just don't buy this. It's going to work fine when you ONLY have the
Seam interceptors, and don't have any other interceptors. As soon as
you start adding your own interceptors, or the interceptors of another
framework, it's HIGHLY likely that you're going to need to specify
their precedence w.r.t. the Seam interceptors.

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

Thanks for the lecture on the need to make things easy for users.
Clearly it's an issue that had not occurred to me before. Wow, I had
never considered thinking of things from the POV of a user!

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

And how is this solution easier than just giving people a standard,
pre-written beans.xml file that they include in their Seam projects as
a starting point? It can even be added automatically by JBoss Tools or
the Maven archectype. Then, when they come to add their own
interceptors, it's easy to just edit this file.

Including a jar in the classpath is actually much more work than
including a pre-written beans.xml file!


--