Well, that's the way we defined it in CDI-1.1 as a compromise.
You can see CDI-18 for more information about the why and how.
LieGrue,
strub
----- Original Message -----
> From: Tang Yong <tangyong_at_cn.fujitsu.com>
> To: Pete Muir <pete.muir_at_gmail.com>
> Cc: Bill Shannon <bill.shannon_at_oracle.com>; Mark Struberg <struberg_at_yahoo.de>; "users_at_javaee-spec.java.net" <users_at_javaee-spec.java.net>
> Sent: Saturday, 19 October 2013, 12:16
> Subject: Re: [javaee-spec users] Re: About Interceptors's enabling
>
> Peter,
>
> My real question is that : " Is the fact that using @Priority
> automatically enables interceptors *reasonable*? "
>
> I think that the spec should not let @Priority automatically enables
> interceptors, either enabling interceptors in beans.xml explicitly or by
> other annotation, eg. "@Interceptor". Instead, @Priority is only used
> for defining order of interceptors.
>
> Thanks
> Tang
>
> Bill Shannon wrote:
>> I agree, it sounds like an implementation bug. Please file a bug
>> against GlassFish <https://java.net/jira/browse/GLASSFISH>.
>>
>> Mark Struberg wrote on 10/18/13 09:13:
>>> I'd say that's an impl bug.
>>>
>>> beans.xml and @Priority only say IF and in which order the interceptor
>>> is enabled. But it still is there only once.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
> ------------------------------------------------------------------------
>>> *From:* John D. Ament <john.d.ament_at_gmail.com>
>>> *To:* users_at_javaee-spec.java.net
>>> *Cc:* Tang Yong <tangyong_at_cn.fujitsu.com>; Pete Muir
>>> <pete.muir_at_gmail.com>; Bill Shannon
> <bill.shannon_at_oracle.com>
>>> *Sent:* Thursday, 17 October 2013, 15:24
>>> *Subject:* [javaee-spec users] Re: About Interceptors's
> enabling
>>>
>>> I wonder if this is somehow related to an issue I saw pop up on SO
>>> recently.
>>>
>>> Basically, there's an issue where if an interceptor is
> annotated
>>> @Priority and listed in beans.xml, it gets invoked twice.
>>>
>>> Is this the expected behavior?
>>>
>>> John
>>>
>>> On Thu, Oct 17, 2013 at 9:12 AM, Pete Muir
>>> <pmuir_at_bleepbleep.org.uk
> <mailto:pmuir_at_bleepbleep.org.uk>> wrote:
>>> > Hi Tang,
>>> >
>>> > I'm afraid I don't quite understand your question :-(
>>> >
>>> > Perhaps you could provide a concrete example of what you would
>>> prefer?
>>> >
>>> > Pete
>>> >
>>> > On 17 Oct 2013, at 09:03, Tang Yong
> <tangyong_at_cn.fujitsu.com
>>> <mailto:tangyong_at_cn.fujitsu.com>> wrote:
>>> >
>>> >> Pete
>>> >> CC: Bill
>>> >>
>>> >> I have a question about Interceptors's enabling.
>>> >>
>>> >> The story should come from [1] and [2], and from "5.3
> Ordering
>>> >> Interceptors using the Priority Annotation" of JSR
> 318.
>>> >>
>>> >> "An interceptor bound to a component, a component
> method, or
>>> constructor
>>> >> using interceptor binding may be enabled for the entire
>>> application by
>>> >> applying the Priority annotation, along with a priority
> value,
>>> on the
>>> >> interceptor class."
>>> >>
>>> >> From another fact, Interceptors are deployment-specific
> and are
>>> disabled
>>> >> by default. Like alternatives, interceptors have to be
>>> >> enabled by using the CDI deployment descriptor beans.xml
> of the
>>> jar.
>>> >>
>>> >> Well, if I uses interceptors binding, I will meet two
> cases,
>>> >>
>>> >> 1) I must enable interceptors in beans.xml explicitly if I
> am
>>> not ready
>>> >> to use @Priority.
>>> >>
>>> >> 2) Once I uses @Priority, I need to take care of whether
> to need to
>>> >> declare interceptors in beans.xml becase this may
> break/override
>>> >> invocation order of interceptors.
>>> >>
>>> >> Based on such facts, enable interceptors in beans.xml
>>> explicitly has
>>> >> brought two different resposibilities for interceptors
> binding,
>>> so, for
>>> >> an user, this has caused some puzzles just as I made a
> mistake
>>> in [2].
>>> >>
>>> >> My question is that why we can not make "enable
> interceptors in
>>> >> beans.xml explicitly" bring *only one* resposibility?
>>> >>
>>> >> Thanks
>>> >> Tang
>>> >>
>>> >> [1]:
>>> >>
>>>
> https://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2012-12/message/15
>>> >> [2]: https://issues.jboss.org/browse/WELD-1528
>>> >>
>>> >>
>>> >> --
>>> >> －－－－－－－－－－－－－－－－－－－－－－
>>> >> Tang Yong
>>> >> Senior Engineer
>>> >> GlassFish Committer (OSGi & OSGi-JavaEE)
>>> >> OSGi Alliance Supporter
>>> >> Blog: http://osgizone.typepad.com/tangyong/
>>> >>
>>> >> Nanjing Fujitsu NanDa Software Tec CO.,LTD
>>> >> http://www.fujitsu.com/cn/fnst
>>> >> Tel: +86-25-86630566-8310
>>> >> Fax: +86-25-83317685
>
>>> >> －－－－－－－－－－－－－－－－－－－－－－
>>> >>
>>> >
>>>
>>>
>>
>
> --
> －－－－－－－－－－－－－－－－－－－－－－
> Tang Yong
> Senior Engineer
> GlassFish Committer (OSGi & OSGi-JavaEE)
> OSGi Alliance Supporter
> Blog: http://osgizone.typepad.com/tangyong/
>
> Nanjing Fujitsu NanDa Software Tec CO.,LTD
> http://www.fujitsu.com/cn/fnst
> Tel: +86-25-86630566-8310
> Fax: +86-25-83317685
> －－－－－－－－－－－－－－－－－－－－－－
>