[seam-dev] Interceptor packaging convention

[Lincoln Baxter, III]

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 at 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 at lists.jboss.org [seam-dev-bounces at lists.jboss.org]
>> On Behalf Of Shane Bryzak [sbryzak at 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 at lists.jboss.org<mailto:seam-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>>
>>
>
>


-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100325/8abb8e7f/attachment-0001.html