This sounds wrong to me.
It is part of the design of CDI that you are *supposed* to be able to
have an annotation with no enabled interceptor.
That let's you, for example, disable your transaction and security
interceptors in the test environment.
So I don't think that you guys should be doing any additional checking
at startup beyond what Weld does as required by the spec.
On Thu, Mar 25, 2010 at 8:14 PM, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com> wrote:
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:
Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
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:
A consistent naming scheme to help prevent typos.
A safety net to catch them when they fall down (because we forgot to tie the
ladder.)
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 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"
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org