Hi,
Pooled annotation would be really cool, as pooling is what makes EJB still
much more efficient than CDI in certain scenarios (
https://github.com/samolisov/spring-vs-ejb-vs-cdi-benchmark).
I see that there is no single concept that could be used in a CDI extension
to support this annotation. There is no hook to release pooled bean in the
Context, and interceptors are called too late after bean creation.
I had an idea to mix context AND interceptor to make Pooled beans possible
already in JavaEE 7. The only tricky part is to pass information from
context, where the bean is allocated, to the interceptor, where it should
be released. I assume that pooled beans should be used only within single
thread, therefore I think that info can be passed using global thread-local
variable.
Here is a pull request to existing code in omnifaces playground repo to
demonstrate the idea:
https://github.com/omnifaces/cdi-ejb/pull/1
It is not yet 100% ready, but it should work in a simple case.
What do you think about it? Would it work in all scenarios?
Ondrej Mihalyi
2016-02-24 15:51 GMT+01:00 arjan tijms <arjan.tijms_at_gmail.com>:
> 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
>>>
>>>
>>>
>>
>>
>