users@javaee-spec.java.net

[javaee-spec users] Re: [jsr366-experts] Interceptor spec MR

From: Reza Rahman <reza_rahman_at_lycos.com>
Date: Wed, 24 Feb 2016 10:19:20 -0500

It's definitely one of the hardest EJBesque features to implement in CDI. Very courageous of you to even try actually.

A closely related and perhaps more generally useful @MaxConcurrency is a lot easier. Adam mentioned that one in the EJB EG years ago - of course without any follow up on the specification lead side. Perhaps simply implementing it for the community and then thinking about standardization later would have been and still is the more effective route...

> On Feb 24, 2016, at 9:51 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
> Hi,
>
>> On Wed, Feb 24, 2016 at 3:22 PM, Reza Rahman <reza_rahman_at_lycos.com> wrote:
>> Are you thinking of something like an @Pooled annotation? I think this could be very useful indeed for certain use cases. In fact I had suggested this within the context of JMS 2.
>
> Indeed, an @Pooled annotation. Appeared to be surprisingly difficult/non-trivial to implement with how Interceptors and the CDI Context currently works.
>
>
>
>>
>> On Feb 24, 2016, at 8:27 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:g e
>>
>>> p.s.
>>>
>>> A small feature request, but what about the ability for Interceptors to intercept before bean resolution has taken place? E.g. in CDI before Context#get is being called.
>>>
>>> This could be done without API changes by using a negative value in @Priority for this.
>>>
>>> The use case is implementing something like the EJB implicit pooling feature of @Stateless beans. This is very hard to do with interceptors that only get called after a bean instance is created.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>> On Wed, Feb 24, 2016 at 10:42 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>>> Hi,
>>>>
>>>>> On Wed, Feb 24, 2016 at 12:54 AM, Linda DeMichiel <linda.demichiel_at_oracle.com> wrote:
>>>>> My expectation is that this
>>>>> would be an "errata MR" (Rev A) as I am not planning any API changes.
>>>>
>>>> Should the MR result in any need for behaviour changes, is there any plan or roadmap to apply these changes to GlassFish 5?
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>>
>>>
>