On Thu, Mar 25, 2010 at 11:25 PM, Lincoln Baxter, III
<lincolnbaxter@gmail.com> wrote:
Agreed - Dan and I were both very upset when we found out about this restriction. Then we spent a little while establishing these guidelines - We're open to other options, but assuming we had to deal with what we have today, that's what we came up with. I think it's a decent approach until we can get some automatic registration support.
On Thu, Mar 25, 2010 at 9:05 PM, Shane Bryzak
<sbryzak@redhat.com> wrote:
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@lists.jboss.org [seam-dev-bounces@lists.jboss.org] On Behalf Of Shane Bryzak [sbryzak@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
--