[seam-dev] Interceptor packaging convention

[Lincoln Baxter, III]

I should add, if anyone finds a way to get around this limitation -- it will
help all of us avoid a lot of pain.

On Thu, Mar 25, 2010 at 11:25 PM, Lincoln Baxter, III <
lincolnbaxter at 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 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"
>



-- 
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/20100326/9dc5a1e8/attachment-0001.html