[seam-dev] Interceptor packaging convention

[Dan Allen]

On Thu, Mar 25, 2010 at 11:25 PM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:

> Agreed - Dan and I were both very upset when we found out about this
> restriction. Then we spent a little while establishing these guidelines -
> We're open to other options, but assuming we had to deal with what we have
> today, that's what we came up with. I think it's a decent approach until we
> can get some automatic registration support.
>
> I should add the pretext that Lincoln and I discussed this for two hours,
so we didn't come to our conclusion lightly :)

On Thu, Mar 25, 2010 at 11:25 PM, Nicklas Karlsson <nickarls at gmail.com
> wrote:

> Perhaps I'm missing something here but can't the ProcessModule event from
> 11.5.5 fix this with List<Class> getInterceptors()?


Two things. First, the ProcessModule did not make CDI 1.0, but was added
later. I'm not sure if the version containing it has been "released" or
approved. Second, that only gets you the interceptors. Lincoln and I were
tricked by that a couple of times...what we need is to modify the
*enabled*interceptors. That's where we keep getting bitten.

If you think long and hard about it, though, there is no way getting around
the fact that you need a single place (at least per module) where
interceptors are ordered absolutely. And that place must know about all the
interceptors that are to be used. Although interceptor ordering might not
often apply to an invocation, you need 100% assurance here, that is
consistent across all beans that join more than one interceptor.

Remember, in EJB 3.0, we had @Interceptors({Foo.class, Bar.class}), but
another developer could write it @Interceptors({Bar.class, Foo.class}) and
that potential for inconsistency is bad.

Maybe you'll be surprised (since I value simplicity as does Lincoln and
others) that Gavin's insistence on having this defined in the module's
beans.xml is the right thing. I don't like it for the same reasons as you,
because we are putting the interceptor classes right in the developer's face
and making him/her deal with enabling them in the right order.

The alternative, which is how it was done in Seam 2, is to have relative
ordering. So you say "this interceptor comes before these but after those
other ones". You could do that at the interceptor-level or by the bean
archive's beans.xml (this beans.xml comes before these but after those other
ones). <- same as listeners in JSF 2 and Servlet 3

In conclusion, let me remind you that the reason we have this problem is
because CDI extensions are not a closed system like Seam 2. In Seam 2, we
knew about every interceptor that existed and we could calculate the right
order for them. Now, any number of extensions can supply any interceptor and
not every extension can know about every other extension. And it may even
come down to the fact that a developer might want an interceptor from one
extension to be applied in a different order than another developer. It all
depends on what the interceptor is doing.

So what Lincoln and I decided was to make this as *easy* as possible on the
developer. And the consistent packaging of interceptors in Seam is
paramount. One possible alternative is to give interceptors aliases (@Named)
so the developer can activate the function ("seam.security") and not the
class ("org.jboss.seam.intercept.SecurityInterceptor").

-Dan

-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100326/cf81c368/attachment-0001.html