Seam Devs,<br><br>
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: <a href="http://seamframework.org/Community/EnablingAnInterceptorInALibrary" target="_blank">http://seamframework.org/Community/EnablingAnInterceptorInALibrary</a> )<br>
<br>This presents an interesting issue; we want to be providing a good out-of-box experience, but interceptors must be registered manually.<br><br>This means that @Interceptor classes must be:<br><ul><li>Exposed to the developer</li>
<li>Registered manually by the developer in beans.xml - <interceptors>...</interceptors><br></li><li>Consistently named and packaged to prevent refactoring / backwards compatibility issues</li><li>Checked at startup in order to warn devs that they are using annotations with no enabled @Interceptor<br>
</li></ul>We would like to propose the following conventions in order to address the above concerns:<br><br>All @Interceptor classes must:<br><ol><li>Adhere to the following package and naming scheme: org.jboss.seam.intercept.*Interceptor<br>
</li><li>Warn users (or Error out when appropriate) if they are using interceptable @Annotations when the @Inteceptor itself is not registered:<br>(@Interceptor registration can be checked in the Extension class AfterBeanDiscovery via BeanManager.resolveInterceptors(type, interceptorBindings)<br>
</li></ol>This presents users with:<br><ol><li>A consistent naming scheme to help prevent typos.</li><li>A safety net to catch them when they fall down (because we forgot to tie the ladder.)</li><li>A protected namespace so that when we refactor, we don't break their world. (Even though #2 would catch it.)<br>
</li></ol>I've updated the <a href="http://seamframework.org/Seam3/DevelopmentGuidelines" target="_blank">Seam 3 Development Guidelines</a> to reflect these conventions - they can be changed as needed pending the outcome of this discussion :)<br>
<br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br><a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>"Keep it Simple"<br>