[seam-dev] Interceptor packaging convention

Seam Devs, Dan and I have been working on the @Begin and @End conversation support for Seam Faces, and we've discovered that there is a new fact of life for consumers of portable CDI extensions. Due to the fact that @Interceptors cannot be enabled in the extensions themselves (due to restrictions on beans.xml for purposes of absolute ordering in the application. See: http://seamframework.org/Community/EnablingAnInterceptorInALibrary ) This presents an interesting issue; we want to be providing a good out-of-box experience, but interceptors must be registered manually. This means that @Interceptor classes must be: - Exposed to the developer - Registered manually by the developer in beans.xml - <interceptors>...</interceptors> - Consistently named and packaged to prevent refactoring / backwards compatibility issues - Checked at startup in order to warn devs that they are using annotations with no enabled @Interceptor We would like to propose the following conventions in order to address the above concerns: All @Interceptor classes must: 1. Adhere to the following package and naming scheme: org.jboss.seam.intercept.*Interceptor 2. Warn users (or Error out when appropriate) if they are using interceptable @Annotations when the @Inteceptor itself is not registered: (@Interceptor registration can be checked in the Extension class AfterBeanDiscovery via BeanManager.resolveInterceptors(type, interceptorBindings) This presents users with: 1. A consistent naming scheme to help prevent typos. 2. A safety net to catch them when they fall down (because we forgot to tie the ladder.) 3. A protected namespace so that when we refactor, we don't break their world. (Even though #2 would catch it.) I've updated the Seam 3 Development Guidelines<http://seamframework.org/Seam3/DevelopmentGuidelines>to reflect these conventions - they can be changed as needed pending the outcome of this discussion :) -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"