First of all: been there done that ;)
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. 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.
The only part where the EJB spec does define such things imo is that the container throws away instances when an Exception happens. Is that a MUST or even a MAY? All other things are pretty surely MAY.
Anyway, that might get done with an Interceptor and an AlterableContext easily.
Pooling get/create is done in Context#get() and removing from the pool at the end of a request or in the interceptor via the @RequestScoped CurrentThreadEjbs
You can also spare all the @RequestScoped bean storage if you integrate the end thread / end request handling all yourself (Servlet Listener, etc). Would be a tick faster, but less portable and have more integration overhead.
So I'd say we don't need any additional feature in the interceptors spec to solve this problem.
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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>