Re: [seam-dev] Interceptor packaging convention

That seems like an appropriate interim solution to me. We really need to be on our toes when it comes to "complexity creep", and having auto-registered interceptors should be a given seeing as our long-time modus operandi has always been about providing sensible defaults. On 26/03/10 10:31, Stuart Douglas wrote: > We could possibly add a non-portable way of doing this automatically for > weld, document that if you are using a different CDI provider you need to do > this manually and push to get it included in a later revision of the spec? > > Stuart > > > ________________________________________ > From: seam-dev-bounces(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org] > On Behalf Of Shane Bryzak [sbryzak(a)redhat.com] > Sent: Friday, 26 March 2010 11:27 AM > To: Lincoln Baxter, III > Cc: Seam Dev List > Subject: Re: [seam-dev] Interceptor packaging convention > > 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: > > 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" > > > > > _______________________________________________ > seam-dev mailing list > seam-dev@lists.jboss.org<mailto:seam-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/seam-dev > > > >