Hi Adam,
Thanks for the feedback. A few comments inline below....
regards,
-Linda
On 2/25/16 5:33 AM, Adam Bien wrote:
> Hi Linda,
>
> a good read.
>
> Feedback
>
> OPEN ISSUE 1:
>
> Should be extended to constructors.
>
> OPEN ISSUE 2:
>
> What if an around-construct method intercepts a constructor that throws a checked exception?”
>
> Is the around-construct interceptor method allowed to throw checked exceptions? Yes.
>
> Is it allowed to catch/ignore them? Yes.
>
> OPEN ISSUE 3:
>
> What about annotations to define default interceptors? I.e., should we state the follow- ing?:
>
> This would be really used -> I actually forgot to file an issue regarding this. What about extending the @Interceptors @Target to Package?
>
This would be an API change. As such, it would need to be done in a new
version of the spec.
>
> 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"
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>