On Mon, Mar 29, 2010 at 2:47 PM, Lincoln Baxter, III
<lincolnbaxter(a)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!
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org