[seam-dev] Interceptor packaging convention

[Nicklas Karlsson]

I think AfterBeanDiscovery is enough (which is already in the spec) for the
autoenablement extension, right?

We could cast the BeanManager parameter to BeanManagerImpl and enable (and
perhaps sort) all org.seam.* interceptors etc that the BM is aware of. Since
there is a limited number of CDI implementations, we could also cast to
other implementations after checking (non-imported, reflection) which one we
are dealing with.

We could also throw in a

@AutoEnable(before="org.jboss.seam.foo.Interceptor")

annotation if want to control the order manually or if we want to offer
others to use this feature (in a seam context)


On Fri, Mar 26, 2010 at 7:35 PM, Dan Allen <dan.j.allen at gmail.com> wrote:

> On Fri, Mar 26, 2010 at 1:28 PM, Dan Allen <dan.j.allen at gmail.com> wrote:
>
>>
>> On Thu, Mar 25, 2010 at 11:25 PM, Nicklas Karlsson <nickarls at gmail.com
>> > wrote:
>>
>>> Perhaps I'm missing something here but can't the ProcessModule event from
>>> 11.5.5 fix this with List<Class> getInterceptors()?
>>
>>
>> Two things. First, the ProcessModule did not make CDI 1.0, but was added
>> later. I'm not sure if the version containing it has been "released" or
>> approved. Second, that only gets you the interceptors. Lincoln and I were
>> tricked by that a couple of times...what we need is to modify the *
>> enabled* interceptors. That's where we keep getting bitten.
>>
>
> Oops! I was wrong. It does give you read/write access to the enabled
> interceptors. Okay, so this would be a possibility to either add
> interceptors or warn the developer to add them. But this listener would have
> to still know about any and all interceptors that need to be enabled (if the
> modules beans.xml is empty as we want it to be).
>
> So we could provide a seam-interceptor-enabler.jar that would enable any
> Seam interceptors on the classpath. We would only provide one such JAR file.
> This is the right way to go. It only requires that we depend on the latest
> version of the spec, which Weld doesn't yet support fully (not ProcessModule
> at least).
>
> Therefore, we have two possible ways forward. The developer lists out the
> interceptors or we provide an enabler JAR. But remember, observer call order
> is not portable, so if you have another enabler JAR from another extension
> library, then how to order them gets tricky. The enabler really needs to be
> a closed system.
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>


-- 
---
Nik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100327/0347f413/attachment-0001.html