+1 for Lincolns arguments
*) I DO use this in production already.
*) I have 3 frameworks with CDI interceptors now
*) they all DON't interfere currently. There are such cases, but they are way less
than 5% in my experience (from 4 years of working with spring interceptors).
*) it's nowhere mentioned in the spec that there must only be one beans.xml with a
<interceptor> section.
IF you really need a hard dependency, would providing a portable extension (in it's
own jar aka bean archive) which modifies the ProcessModule#getInterceptors() and fills it
with a extension specific configured ordered list of interceptors help?
LieGrue,
strub
--- Gavin King <gavin.king(a)gmail.com> schrieb am Mo, 29.3.2010:
Von: Gavin King <gavin.king(a)gmail.com>
Betreff: Re: [seam-dev] Interceptor packaging convention
An: "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com>
CC: "Seam Dev List" <seam-dev(a)lists.jboss.org>
Datum: Montag, 29. März, 2010 20:56 Uhr
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
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen
Massenmails.
http://mail.yahoo.com