[seam-dev] Interceptor packaging convention

[Gavin King]

It's an even worse major inconvenience to not be able to turn interceptors off.

On Thu, Mar 25, 2010 at 8:27 PM, Shane Bryzak <sbryzak at redhat.com> wrote:
> This will be a major inconvenience for our users if we expect them to
> manually add all the interceptors they need for conversations, security,
> transactions, and who knows what else.  Is there absolutely no other way
> that we can automatically register these in the extension?  Also I'm not a
> big fan of having to use the org.jboss.seam.intercept namespace, I don't
> want to have to include a lone class in this package if all my other classes
> are in (for example the security module) org.jboss.seam.security.
>
> On 26/03/10 10:14, Lincoln Baxter, III 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org