[seam-dev] Interceptor packaging convention

[Nicklas Karlsson]

>
> >>Especially the last sentence definitely makes clear that Lincolns use
> case should 'just work'. I think this is only a bug in Weld being overly
> strict and not in the spec (this works in OWB btw).
>
>
And that should be checked against trunk since I made some changes there and
the stack trace origins from a place that no longer exists...


> b) such a enabler.jar would not work imo in a modular environment, because
> "If there is no class with the specified name, or if the class with the
> specified name is not an interceptor class, the container automatically
> detects the problem and treats it as a deployment problem." So if one jar is
> not in the dependencies, the list must not contain the Interceptors from
> this jar.
>
>
I don't think that's an issue since we would only enable stuff already known
to the bean manager. In fact, it would be safer than enablement through
beans.xml, not?


> LieGrue,
> strub
>
> --- Nicklas Karlsson *<nickarls at gmail.com>* schrieb am *Sa, 27.3.2010:
> *
>
> *
> Von: Nicklas Karlsson <nickarls at gmail.com>
> Betreff: Re: [seam-dev] Interceptor packaging convention
> An: "Dan Allen" <dan.j.allen at gmail.com>
> CC: "Seam Dev List" <seam-dev at lists.jboss.org>
> Datum: Samstag, 27. März, 2010 08:28 Uhr
>
> *
> *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<http://mc/compose?to=dan.j.allen@gmail.com>
> > wrote:
> *
>>
>> *On Fri, Mar 26, 2010 at 1:28 PM, Dan Allen <dan.j.allen at gmail.com<http://mc/compose?to=dan.j.allen@gmail.com>
>> > wrote:
>> *
>>>
>>> *
>>> *
>>> *On Thu, Mar 25, 2010 at 11:25 PM, Nicklas Karlsson <nickarls at gmail.com<http://mc/compose?to=nickarls@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 <http://mc/compose?to=seam-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>> *
>
> *
>
>
> --
> ---
> Nik
> *
> *
> -----Integrierter Anhang folgt-----
>
> *
> *_______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org <http://mc/compose?to=seam-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/seam-dev
> *
>
>
> __________________________________________________
> Do You Yahoo!?
> Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
> gegen Massenmails.
> http://mail.yahoo.com
>



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