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 <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 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
>>>
>>>
>>>
>>
>>
>