users@javaee-spec.java.net

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

From: Mark Struberg <struberg_at_yahoo.de>
Date: Sun, 20 Mar 2016 19:18:58 +0000 (UTC)

The _before_ instance interceptor clashes with the specification that the interceptor is a @Dependent scoped instance of the intercepted bean.

And I think you could easily do that in the Context#get() as explained.

LieGrue,
strub





On Sunday, 20 March 2016, 20:02, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
>Hi,
>
>
>
>On Sun, Mar 20, 2016 at 11:47 AM, Mark Struberg <struberg_at_yahoo.de> wrote:
>
>My implementation didn't return the instance to the pool when the method got ended but only at the end of the request via a @PreDestroy in a @RequestScoped bean.
>
>
>By itself indeed not such a bad idea, but I thought you meant you found a way to get interceptors to execute before Context#get ;)
>
>
>A problem with doing the request scope thing is that it's another compromise. In this case bean instances will be unavailable for a little bit too long, especially if they're used early in the request and the request is a little longer running.
>
>
>It looks like almost every approach compromises in some way. E.g. we did the Javassist approach before, but that one had the dependency as compromise, and the dummy instance return has the single dummy that needs to be maintained as compromise, etc.
>
>
>One of the few ways that seems to be as straightforward as can be and doesn't compromise in any way I think is an interceptor that runs before Context#get does.
>
>
>
>I kind of piggy-packed the EJBs used in the current thread into a @RequestScoped bean. The EJB spec doesn't mandate anything else. The spec does barely mention pooling if I remember correctly. It's just that we are all used to it.
>>
>
>
>Indeed, pooling itself is barely mentioned and certainly not explicitly specified. It's sort of a theme in EJB to leave more aspects to be implementation specific than we're used from other specs.
>
>
>That said, the spec does describe that a bean is available exclusively to a single caller and that instance variables *may* contain values set by a previous caller. Indeed, combined with the concept of destroying beans when certain types of exceptions happen, it does strongly imply something that we would normally call "pooling".
>
>
>
>So I'd say we don't need any additional feature in the interceptors spec to solve this problem.
>>
>
>
>I'm not entirely sure. It's an interesting approach, and I'll sure keep it in the back om my mind so thanks for mentioning it, but a "before interceptor" is likely still a bit more convenient and simultaneously less compromising.
>
>
>Kind regards,
>Arjan Tijms
>
>
>
>
>>LieGrue,
>>strub
>>
>>
>>
>>On Sunday, 20 March 2016, 11:21, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>
>>
>>>
>>>
>>>Hi Mark,
>>>
>>>
>>>
>>>
>>>Patching in Jan Beernkink, who's working on an @Pooled annotation. This is for a CDI version of the pooling feature that's often seen with @Stateless beans. Here we desperately need interceptors to execute before Context#get.
>>>
>>>
>>>Sounds great if there's already a way to have interceptors execute before Context#get is called. Can you give an example of this in code? We tried quite some things but were not able to pull it off.
>>>
>>>
>>>The use case is that the Interceptor should be in charge of managing the pool with bean instances, since its the only thing that runs both before and after a method invocation. The Context#get only runs before, and therefor does not have an opportunity to return bean instances to the pool.
>>>
>>>
>>>See the code here: https://github.com/omnifaces/cdi-ejb/tree/master/src/main/java/org/omnifaces/cdi/pooled
>>>
>>>
>>>Kind regards,
>>>Arjan Tijms
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>On Sun, Mar 20, 2016 at 9:42 AM, Mark Struberg <struberg_at_yahoo.de> wrote:
>>>
>>>Imo it is totally possible with the current interceptors spec.
>>>>
>>>>Do you mind explaining my your problems offline to not trash this thread with offtopic discussions?
>>>>
>>>>
>>>>txs and LieGrue,
>>>>strub
>>>>
>>>>
>>>>
>>>>On Wednesday, 24 February 2016, 14:28, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>>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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>