On Thu, Mar 25, 2010 at 11:25 PM, Lincoln Baxter, III
<lincolnbaxter@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 :)
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