Hi,
On Mon, Feb 29, 2016 at 10:16 PM, Linda DeMichiel <
linda.demichiel_at_oracle.com> wrote:
> This would be an API change. As such, it would need to be done in a new
>> version of the spec.
>>
>
But a MR can also be a new version of the spec, right? Like JSF 2.1, JTA
1.2 and JASPIC 1.1 among others, which were all done as a MR if I'm not
mistaken.
Kind regards,
Arjan Tijms
>
>
>> OPEN ISSUE 4:
>>
>> What happens if a superclass of the target class specifies the Inter-
>> ceptors annotation? Should those interceptors also be run? Previous
>> versions of this specification did not state so, and the RI is inconsistent
>> in its treatment of this case.
>>
>> Yes. Inheritance should also run in the subclass.
>>
>>
> I'd like to gather information here about the behavior of existing
> implementations.
>
> AFAICT, there is a lock of consistency here, also including lack
> of consistency between @ManagedBean beans and EJBS.
>
>
> thank you!,
>>
>> cheers,
>>
>> adam
>>
>>
>>
>>
>> On 24.02.2016, at 21:42, users-request_at_javaee-spec.java.net wrote:
>>>
>>> Table of contents:
>>>
>>> 1. [javaee-spec users] [jsr366-experts] Interceptor spec MR - Linda
>>> DeMichiel <linda.demichiel_at_oracle.com>
>>> 2. [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR - arjan
>>> tijms <arjan.tijms_at_gmail.com>
>>> 3. [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR - arjan
>>> tijms <arjan.tijms_at_gmail.com>
>>> 4. [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR - Reza
>>> Rahman <reza_rahman_at_lycos.com>
>>> 5. [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR - Romain
>>> Manni-Bucau <rmannibucau_at_gmail.com>
>>> 6. [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR - Reza
>>> Rahman <reza_rahman_at_lycos.com>
>>> 7. [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR - arjan
>>> tijms <arjan.tijms_at_gmail.com>
>>> 8. [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR - arjan
>>> tijms <arjan.tijms_at_gmail.com>
>>> 9. [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR - Reza
>>> Rahman <reza_rahman_at_lycos.com>
>>> 10. [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR -
>>> Romain Manni-Bucau <rmannibucau_at_gmail.com>
>>>
>>>
>>> From: Linda DeMichiel <linda.demichiel_at_oracle.com>
>>> Subject: [javaee-spec users] [jsr366-experts] Interceptor spec MR
>>> Date: 24. Februar 2016 um 00:54:48 MEZ
>>> To: jsr366-experts_at_javaee-spec.java.net
>>> Reply-To: jsr366-experts_at_javaee-spec.java.net
>>>
>>>
>>> One of the things I've been working on lately is a cleanup of the
>>> Interceptors spec.
>>>
>>> The intent here is not to change the semantics of the Interceptors 1.2
>>> spec, but to clarify a number of areas that appeared to me somewhat
>>> confusing. I've also flagged several open issues that we need to
>>> either resolve or explicitly specify as portability concerns.
>>>
>>> I would appreciate if you would read the document in its entirety, and
>>> weigh in on the open issues. Also, if you believe that I have
>>> inadvertantly changed the semantics of the spec, please let me know,
>>> as that was not my intent.
>>>
>>> You can download the document here:
>>> https://java.net/projects/javaee-spec/downloads/download/Interceptors021716.pdf
>>>
>>> The document has change-bars that reflect a superset of all changes.
>>> Since this work has also entailed some minor reorganization, the
>>> change-bars are not particularly helpful.
>>>
>>> Once I get feedback on the open issues (and I find time to write some
>>> more extensive examples for the spec), I plan to circulate another
>>> draft in advance of submitting an MR. My expectation is that this
>>> would be an "errata MR" (Rev A) as I am not planning any API changes.
>>>
>>> thanks!
>>>
>>> -Linda
>>>
>>>
>>>
>>> From: arjan tijms <arjan.tijms_at_gmail.com>
>>> Subject: [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR
>>> Date: 24. Februar 2016 um 10:42:54 MEZ
>>> To: users <users_at_javaee-spec.java.net>
>>> Reply-To: users_at_javaee-spec.java.net
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>> From: arjan tijms <arjan.tijms_at_gmail.com>
>>> Subject: [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR
>>> Date: 24. Februar 2016 um 14:27:13 MEZ
>>> To: users <users_at_javaee-spec.java.net>
>>> Reply-To: users_at_javaee-spec.java.net
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: Reza Rahman <reza_rahman_at_lycos.com>
>>> Subject: [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR
>>> Date: 24. Februar 2016 um 15:22:49 MEZ
>>> To: users_at_javaee-spec.java.net
>>> Reply-To: users_at_javaee-spec.java.net
>>>
>>>
>>> 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.
>>>
>>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> From: Romain Manni-Bucau <rmannibucau_at_gmail.com>
>>> Subject: [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR
>>> Date: 24. Februar 2016 um 15:24:39 MEZ
>>> To: "users_at_javaee-spec.java.net" <users_at_javaee-spec.java.net>
>>> Reply-To: users_at_javaee-spec.java.net
>>>
>>>
>>> Not sure how @Pooled is linked to interceptor since it sounds more like
>>> a context which doesn't have this issue. Can you elaborate?
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
>>>
>>> 2016-02-24 15:22 GMT+01:00 Reza Rahman <reza_rahman_at_lycos.com>:
>>> 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.
>>>
>>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> From: Reza Rahman <reza_rahman_at_lycos.com>
>>> Subject: [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR
>>> Date: 24. Februar 2016 um 15:37:36 MEZ
>>> To: users_at_javaee-spec.java.net
>>> Reply-To: users_at_javaee-spec.java.net
>>>
>>>
>>> It sounds like Arjan is already at least prototyping the feature in CDI
>>> so I'll let him explain. If not I'll elaborate what I think is going on in
>>> the use case. We discussed the feature back in my Caucho/Resin days but
>>> never got to implement it. Since we had our own CDI engine implementing
>>> this sort of thing in Resin didn't actually require specification changes...
>>>
>>> On Feb 24, 2016, at 9:24 AM, Romain Manni-Bucau <rmannibucau_at_gmail.com>
>>> wrote:
>>>
>>> Not sure how @Pooled is linked to interceptor since it sounds more like
>>>> a context which doesn't have this issue. Can you elaborate?
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
>>>>
>>>> 2016-02-24 15:22 GMT+01:00 Reza Rahman <reza_rahman_at_lycos.com>:
>>>> 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.
>>>>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> From: arjan tijms <arjan.tijms_at_gmail.com>
>>> Subject: [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR
>>> Date: 24. Februar 2016 um 15:49:42 MEZ
>>> To: users <users_at_javaee-spec.java.net>
>>> Reply-To: users_at_javaee-spec.java.net
>>>
>>>
>>> Hi,
>>> On Wed, Feb 24, 2016 at 3:24 PM, Romain Manni-Bucau <
>>> rmannibucau_at_gmail.com> wrote:
>>> Not sure how @Pooled is linked to interceptor since it sounds more like
>>> a context which doesn't have this issue. Can you elaborate?
>>>
>>> yeah, but you need to allocate a bean before a method call and release
>>> it again afterwards. You can't do that solely with a context. The context
>>> has no knowledge of when the method call ends.
>>>
>>> We've been prototyping this, mainly the work by my co-worker Jan:
>>> https://github.com/omnifaces/cdi-ejb/tree/master/src/main/java/org/omnifaces/cdi/pooled
>>>
>>> With a manual "interceptor" (method handler, from Javassist), that's
>>> returned from a Context, you can do this:
>>>
>>> @Override
>>> public Object invoke(Object o, Method method, Method method1,
>>> Object[] objects) throws Throwable {
>>> PoolKey<T> poolKey =
>>> pooledContext.allocateBean(contextual);
>>>
>>> try {
>>> T bean = pooledContext.getBean(poolKey, context);
>>>
>>> return method.invoke(bean, objects);
>>> }
>>> finally {
>>> pooledContext.releaseBean(poolKey);
>>> }
>>> }
>>>
>>> But the Context has to create that manually:
>>>
>>> public <T> T get(Contextual<T> contextual, CreationalContext<T>
>>> creationalContext) {
>>> Class<T> proxyClass = ((Class<T>)
>>> proxyClasses.computeIfAbsent(contextual, ctx -> {
>>> ProxyFactory factory = new ProxyFactory();
>>>
>>> Class<?> beanClass = ((Bean<?>)
>>> contextual).getBeanClass();
>>>
>>> factory.setSuperclass(beanClass);
>>>
>>> return factory.createClass();
>>> }));
>>>
>>> T instance = proxyClass.newInstance();
>>>
>>> ((Proxy) instance).setHandler(new
>>> WrappedBeanMethodHandler<>(contextual, creationalContext, this));
>>>
>>> return instance;
>>> }
>>>
>>> But the dependency on Javassist is not so optimal. An Interceptor that
>>> runs before the Context is called would be a relatively simple alternative
>>> to the above.
>>>
>>> Another option, which native EJB solutions occasionally use is changing
>>> the target of an Interceptor's invocation context.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
>>>
>>> 2016-02-24 15:22 GMT+01:00 Reza Rahman <reza_rahman_at_lycos.com>:
>>> 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.
>>>
>>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> From: arjan tijms <arjan.tijms_at_gmail.com>
>>> Subject: [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR
>>> Date: 24. Februar 2016 um 15:51:53 MEZ
>>> To: users <users_at_javaee-spec.java.net>
>>> Reply-To: users_at_javaee-spec.java.net
>>>
>>>
>>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> From: Reza Rahman <reza_rahman_at_lycos.com>
>>> Subject: [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR
>>> Date: 24. Februar 2016 um 16:19:20 MEZ
>>> To: users_at_javaee-spec.java.net
>>> Reply-To: users_at_javaee-spec.java.net
>>>
>>>
>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> From: Romain Manni-Bucau <rmannibucau_at_gmail.com>
>>> Subject: [javaee-spec users] Re: [jsr366-experts] Interceptor spec MR
>>> Date: 24. Februar 2016 um 16:40:33 MEZ
>>> To: "users_at_javaee-spec.java.net" <users_at_javaee-spec.java.net>
>>> Reply-To: users_at_javaee-spec.java.net
>>>
>>>
>>> Mark proposed to get a ProxyFactory in CDI - standardize the
>>> interceptor/subclass/... proxying which is done by implementations, for me
>>> it opens the doors of such implementations pretty efficiently.
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
>>>
>>> 2016-02-24 16:19 GMT+01:00 Reza Rahman <reza_rahman_at_lycos.com>:
>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> End of digest for list users_at_javaee-spec.java.net - Wed, 24 Feb 2016
>>>
>>
>> workshops.adam-bien.com
>> effectivejavaee.com
>> blog.adam-bien.com
>> airhacks.news
>>
>> Author of:
>> "Real World Java EE Night Hacks”,
>> "Real World Java EE Patterns— Rethinking Best Practices"
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>