7:59 a.m.
Hi,
I wonder if it would be allowed according to the CDI spec to destroy a
bean instance from within an interceptor.
To test this (on Weld) I used the following code:
@Interceptor
@DestroyOnError
@Priority(APPLICATION)
public class DestroyOnErrorInterceptor implements Serializable {
private static final long serialVersionUID = 1L;
@AroundInvoke
public Object tryInvoke(InvocationContext ctx) throws Exception {
try {
return ctx.proceed();
} catch (Exception e) {
destroy(ctx.getMethod().getDeclaringClass());
throw e;
}
}
private <T> void destroy(Class<T> clazz) {
Instance<T> instance = CDI.current().select(clazz);
instance.destroy(instance.get());
}
}
When I use this interceptor on a SessionScoped bean:
@SessionScoped
public class TestBean implements Serializable {
private static final long serialVersionUID = 1L;
@DestroyOnError
public void test() {
throw new IllegalStateException();
}
}
And then inject said bean in say a Servlet and call the test() method,
destruction of the bean happens partially, but as soon as Weld tried
to invocate a preDestroy method, it goes through the bean proxy again,
detects that "the" interceptor handler is already active, promptly
skips its attempt to call a preDestroy method and then to add insult
to injury tries to call a "proceed" method which is always null and
thus throws a NPE.
(this happens in
org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke)
I tried some alternative methods to destroy the bean such as:
Bean<T> bean = resolve(beanManager, beanClass);
AlterableContext context = (AlterableContext)
beanManager.getContext(bean.getScope());
context.destroy(bean);
with resolve being:
public static <T> Bean<T> resolve(BeanManager beanManager, Class<T>
beanClass) {
Set<Bean<?>> beans = beanManager.getBeans(beanClass);
for (Bean<?> bean : beans) {
if (bean.getBeanClass() == beanClass) {
return (Bean<T>)
beanManager.resolve(Collections.<Bean<?>>singleton(bean));
}
}
return (Bean<T>) beanManager.resolve(beans);
}
But this resulted in the same problem.
Any idea?
Kind regards,
Arjan Tijms
9:21 a.m.
Did I understand this correctly? You like to destroy the contextual instance you are
currently intercepting?
If so, then I fear you would effectively kill yourself.
Please remember that an interceptor and decorator is per specification always a @Dependent
scoped 1:1 instance of the contextual instance it intercepts or decorates. Thus it also
gets stored in the CreationalContext of your very contextual instance. And by destroying
the contextual instance it's CreationalContext gets properly cleaned up and destroyed
as well. While doing so it will also destroy your interceptor/decorator.
Doesn't sound that healthy to me...
Maybe that might work for simple examples, but don't forget that real world apps are
no samples but much more complex and the side effects might be really ugly and highly
non-portable. Have a bad gut feeling about it.
LieGrue,
strub
On Monday, 10 November 2014, 14:59, arjan tijms
<arjan.tijms(a)gmail.com> wrote:
> Hi,
I wonder if it would be allowed according to the CDI spec to destroy a
bean instance from within an interceptor.
To test this (on Weld) I used the following code:
@Interceptor
@DestroyOnError
@Priority(APPLICATION)
public class DestroyOnErrorInterceptor implements Serializable {
private static final long serialVersionUID = 1L;
@AroundInvoke
public Object tryInvoke(InvocationContext ctx) throws Exception {
try {
return ctx.proceed();
} catch (Exception e) {
destroy(ctx.getMethod().getDeclaringClass());
throw e;
}
}
private <T> void destroy(Class<T> clazz) {
Instance<T> instance = CDI.current().select(clazz);
instance.destroy(instance.get());
}
}
When I use this interceptor on a SessionScoped bean:
@SessionScoped
public class TestBean implements Serializable {
private static final long serialVersionUID = 1L;
@DestroyOnError
public void test() {
throw new IllegalStateException();
}
}
And then inject said bean in say a Servlet and call the test() method,
destruction of the bean happens partially, but as soon as Weld tried
to invocate a preDestroy method, it goes through the bean proxy again,
detects that "the" interceptor handler is already active, promptly
skips its attempt to call a preDestroy method and then to add insult
to injury tries to call a "proceed" method which is always null and
thus throws a NPE.
(this happens in
org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke)
I tried some alternative methods to destroy the bean such as:
Bean<T> bean = resolve(beanManager, beanClass);
AlterableContext context = (AlterableContext)
beanManager.getContext(bean.getScope());
context.destroy(bean);
with resolve being:
public static <T> Bean<T> resolve(BeanManager beanManager,
Class<T> beanClass) {
Set<Bean<?>> beans = beanManager.getBeans(beanClass);
for (Bean<?> bean : beans) {
if (bean.getBeanClass() == beanClass) {
return (Bean<T>)
beanManager.resolve(Collections.<Bean<?>>singleton(bean));
}
}
return (Bean<T>) beanManager.resolve(beans);
}
But this resulted in the same problem.
Any idea?
Kind regards,
Arjan Tijms
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code
under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
on this list, the provider waives all patent and other intellectual property
rights inherent in such information.
9:43 a.m.
Hi,
On Mon, Nov 10, 2014 at 4:21 PM, Mark Struberg <struberg(a)yahoo.de> wrote:
Did I understand this correctly? You like to destroy the contextual
instance you are currently intercepting?
Indeed, I hoped that if the interceptor method that called the destroy
doesn't do anything after that call and just immediately exits there
could be little harm done.
If so, then I fear you would effectively kill yourself.
Perhaps, so that's unfortunate indeed. It -does- work when another
request thread within the same session calls the destroy method, even
when the first thread is still inside the session scoped bean or
interceptor. This other thread apparently gets a different proxy
instance.
Doesn't sound that healthy to me...
Do you know of any other way via which I could automatically destroy a
bean after an exception? What I'm looking for is more of a "pure
interceptor"; a stateless interceptor that depends on nothing.
Basically what I would get if I manually wrapped an object.
As such I've been looking for a way to wrap the proxy that CDI
injects, but as of yet I haven't found a way to do so.
What I'm trying to implement is a copy of the feature EJB session
beans have, where a bean instance is by default automatically
destroyed after a (system) exception.
Kind regards,
Arjan Tijms
Maybe that might work for simple examples, but don't forget that real world apps are
no samples but much more complex and the side effects might be really ugly and highly
non-portable. Have a bad gut feeling about it.
LieGrue,
strub
> On Monday, 10 November 2014, 14:59, arjan tijms <arjan.tijms(a)gmail.com> wrote:
> > Hi,
>
> I wonder if it would be allowed according to the CDI spec to destroy a
> bean instance from within an interceptor.
>
> To test this (on Weld) I used the following code:
>
> @Interceptor
> @DestroyOnError
> @Priority(APPLICATION)
> public class DestroyOnErrorInterceptor implements Serializable {
>
> private static final long serialVersionUID = 1L;
>
> @AroundInvoke
> public Object tryInvoke(InvocationContext ctx) throws Exception {
>
> try {
> return ctx.proceed();
> } catch (Exception e) {
> destroy(ctx.getMethod().getDeclaringClass());
> throw e;
> }
> }
>
> private <T> void destroy(Class<T> clazz) {
> Instance<T> instance = CDI.current().select(clazz);
> instance.destroy(instance.get());
> }
>
> }
>
>
> When I use this interceptor on a SessionScoped bean:
>
> @SessionScoped
> public class TestBean implements Serializable {
>
> private static final long serialVersionUID = 1L;
>
> @DestroyOnError
> public void test() {
> throw new IllegalStateException();
> }
> }
>
> And then inject said bean in say a Servlet and call the test() method,
> destruction of the bean happens partially, but as soon as Weld tried
> to invocate a preDestroy method, it goes through the bean proxy again,
> detects that "the" interceptor handler is already active, promptly
> skips its attempt to call a preDestroy method and then to add insult
> to injury tries to call a "proceed" method which is always null and
> thus throws a NPE.
>
> (this happens in
> org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke)
>
> I tried some alternative methods to destroy the bean such as:
>
>
> Bean<T> bean = resolve(beanManager, beanClass);
>
> AlterableContext context = (AlterableContext)
> beanManager.getContext(bean.getScope());
> context.destroy(bean);
>
> with resolve being:
>
> public static <T> Bean<T> resolve(BeanManager beanManager,
> Class<T> beanClass) {
> Set<Bean<?>> beans = beanManager.getBeans(beanClass);
>
> for (Bean<?> bean : beans) {
> if (bean.getBeanClass() == beanClass) {
> return (Bean<T>)
> beanManager.resolve(Collections.<Bean<?>>singleton(bean));
> }
> }
>
> return (Bean<T>) beanManager.resolve(beans);
> }
>
> But this resulted in the same problem.
>
> Any idea?
>
> Kind regards,
> Arjan Tijms
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
> on this list, the provider waives all patent and other intellectual property
> rights inherent in such information.
>
10:18 a.m.
p.s.
Not sure if I'm venturing even deeper in no-no land now, but if I wrap
the InjectionTarget for a bean with the @DestroyOnError annotation and
subsequently do nothing in the void preDestroy(X instance) method,
then everything -seems- to work.
12:49 p.m.
Hi Arjan,
there is a bug in Weld (WELD-1785) preventing this from working which is
going to be fixed in the next release. What you are doing should work
IMO as long as the interceptor does not call any other methods on the
target instance. In addition it must count with the target instance
being destroyed within the instance.destroy() call.
Perhaps a nicer way of doing this would be:
@Inject
@Intercepted
private Bean<?> bean;
Context context = manager.getContext(bean.getScope());
if (!(context instanceof AlterableContext)) {
throw new IllegalStateException("Context does not support
removal of instances");
}
AlterableContext alterableContext =
AlterableContext.class.cast(context);
alterableContext.destroy(bean);
On 11/10/2014 02:59 PM, arjan tijms wrote:
Hi,
I wonder if it would be allowed according to the CDI spec to destroy a
bean instance from within an interceptor.
To test this (on Weld) I used the following code:
@Interceptor
@DestroyOnError
@Priority(APPLICATION)
public class DestroyOnErrorInterceptor implements Serializable {
private static final long serialVersionUID = 1L;
@AroundInvoke
public Object tryInvoke(InvocationContext ctx) throws Exception {
try {
return ctx.proceed();
} catch (Exception e) {
destroy(ctx.getMethod().getDeclaringClass());
throw e;
}
}
private <T> void destroy(Class<T> clazz) {
Instance<T> instance = CDI.current().select(clazz);
instance.destroy(instance.get());
}
}
When I use this interceptor on a SessionScoped bean:
@SessionScoped
public class TestBean implements Serializable {
private static final long serialVersionUID = 1L;
@DestroyOnError
public void test() {
throw new IllegalStateException();
}
}
And then inject said bean in say a Servlet and call the test() method,
destruction of the bean happens partially, but as soon as Weld tried
to invocate a preDestroy method, it goes through the bean proxy again,
detects that "the" interceptor handler is already active, promptly
skips its attempt to call a preDestroy method and then to add insult
to injury tries to call a "proceed" method which is always null and
thus throws a NPE.
(this happens in
org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke)
I tried some alternative methods to destroy the bean such as:
Bean<T> bean = resolve(beanManager, beanClass);
AlterableContext context = (AlterableContext)
beanManager.getContext(bean.getScope());
context.destroy(bean);
with resolve being:
public static <T> Bean<T> resolve(BeanManager beanManager, Class<T>
beanClass) {
Set<Bean<?>> beans = beanManager.getBeans(beanClass);
for (Bean<?> bean : beans) {
if (bean.getBeanClass() == beanClass) {
return (Bean<T>)
beanManager.resolve(Collections.<Bean<?>>singleton(bean));
}
}
return (Bean<T>) beanManager.resolve(beans);
}
But this resulted in the same problem.
Any idea?
Kind regards,
Arjan Tijms
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
9:27 a.m.
Hi,
On Wednesday, November 12, 2014, Jozef Hartinger <jharting(a)redhat.com>
wrote:
Hi Arjan,
there is a bug in Weld (WELD-1785) preventing this from working which is
going to be fixed in the next release. What you are doing should work IMO
as long as the interceptor does not call any other methods on the target
instance.
That's great to hear really.
I'm slightly confused through why Mark thinks this cannot really work,
while you say it should.
Is there something in the spec that may need to be clarified here? Ie some
words about what an interceptor is at least allowed to do and what is
definitely not allowed?
In addition it must count with the target instance being destroyed
within
the instance.destroy() call.
Sorry, I don't fully follow this. You mean something must be counted?
Perhaps a nicer way of doing this would be:
@Inject
@Intercepted
private Bean<?> bean;
Context context = manager.getContext(bean.getScope());
if (!(context instanceof AlterableContext)) {
throw new IllegalStateException("Context does not support
removal of instances");
}
AlterableContext alterableContext = AlterableContext.class.cast(
context);
alterableContext.destroy(bean);
I tried something close to that as well, just used the bean manager to
resolve a Bean from the target object. Thanks for the suggestion!
Kind regards,
Arjan
On 11/10/2014 02:59 PM, arjan tijms wrote:
> Hi,
>
> I wonder if it would be allowed according to the CDI spec to destroy a
> bean instance from within an interceptor.
>
> To test this (on Weld) I used the following code:
>
> @Interceptor
> @DestroyOnError
> @Priority(APPLICATION)
> public class DestroyOnErrorInterceptor implements Serializable {
>
> private static final long serialVersionUID = 1L;
>
> @AroundInvoke
> public Object tryInvoke(InvocationContext ctx) throws Exception {
>
> try {
> return ctx.proceed();
> } catch (Exception e) {
> destroy(ctx.getMethod().getDeclaringClass());
> throw e;
> }
> }
>
> private <T> void destroy(Class<T> clazz) {
> Instance<T> instance = CDI.current().select(clazz);
> instance.destroy(instance.get());
> }
>
> }
>
>
> When I use this interceptor on a SessionScoped bean:
>
> @SessionScoped
> public class TestBean implements Serializable {
>
> private static final long serialVersionUID = 1L;
>
> @DestroyOnError
> public void test() {
> throw new IllegalStateException();
> }
> }
>
> And then inject said bean in say a Servlet and call the test() method,
> destruction of the bean happens partially, but as soon as Weld tried
> to invocate a preDestroy method, it goes through the bean proxy again,
> detects that "the" interceptor handler is already active, promptly
> skips its attempt to call a preDestroy method and then to add insult
> to injury tries to call a "proceed" method which is always null and
> thus throws a NPE.
>
> (this happens in
> org.jboss.weld.bean.proxy.CombinedInterceptorAndDecorato
> rStackMethodHandler.invoke)
>
> I tried some alternative methods to destroy the bean such as:
>
>
> Bean<T> bean = resolve(beanManager, beanClass);
>
> AlterableContext context = (AlterableContext)
> beanManager.getContext(bean.getScope());
> context.destroy(bean);
>
> with resolve being:
>
> public static <T> Bean<T> resolve(BeanManager beanManager,
Class<T>
> beanClass) {
> Set<Bean<?>> beans = beanManager.getBeans(beanClass);
>
> for (Bean<?> bean : beans) {
> if (bean.getBeanClass() == beanClass) {
> return (Bean<T>)
> beanManager.resolve(Collections.<Bean<?>>singleton(bean));
> }
> }
>
> return (Bean<T>) beanManager.resolve(beans);
> }
>
> But this resulted in the same problem.
>
> Any idea?
>
> Kind regards,
> Arjan Tijms
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
2:14 a.m.
I did not say it cannot work but that it is not guaranteed to work. It's just totally
up to implementation details of the container and your actual situation. Basically
it's non-portable at best.
E.g. consider the case that you are NOT the outermost interceptor but there are 2 other
decorators and interceptors. The decorators will probably not hurt much as they are
defined to be called _after_ interceptors. But if there is an interceptor in addition to
yours then you will probably kill em and after returning from the chain you might end up
in a dead bean (the other interceptor).
There are just so many things which can go wrong. Even though I like the general idea what
you like to do with that interceptor. But I suggest you probably use another trick. Every
CDI bean must (as per the interceptors spec) support 'self-interception'. Means
you only need to add an @AroundInvoke method and do the re-setup of your CONNECTION inside
your @ApplicationScoped bean (with full access to the underlying business infrastructure).
This is fundamentally different to your approach as I do not ditch the whole service but
only fix the thing which broke in it.
LieGrue,
strub
On Thursday, 13 November 2014, 16:28, arjan tijms <arjan.tijms(a)gmail.com> wrote:
Hi,
On Wednesday, November 12, 2014, Jozef Hartinger <jharting(a)redhat.com> wrote:
Hi Arjan,
>
>there is a bug in Weld (WELD-1785) preventing this from working which is going to be
fixed in the next release. What you are doing should work IMO as long as the interceptor
does not call any other methods on the target instance.
That's great to hear really.
I'm slightly confused through why Mark thinks this cannot really work, while you say
it should.
Is there something in the spec that may need to be clarified here? Ie some words about
what an interceptor is at least allowed to do and what is definitely not allowed?
In addition it must count with the target instance being destroyed within the
instance.destroy() call.
Sorry, I don't fully follow this. You mean something must be counted?
>Perhaps a nicer way of doing this would be:
>
>@Inject
>@Intercepted
>private Bean<?> bean;
>
> Context context = manager.getContext(bean.getScope());
> if (!(context instanceof AlterableContext)) {
> throw new IllegalStateException("Context does not support removal of
instances");
> }
> AlterableContext alterableContext = AlterableContext.class.cast(context);
> alterableContext.destroy(bean);
I tried something close to that as well, just used the bean manager to resolve a Bean from
the target object. Thanks for the suggestion!
Kind regards,
Arjan
>On 11/10/2014 02:59 PM, arjan tijms wrote:
>
>Hi,
>>
>>I wonder if it would be allowed according to the CDI spec to destroy a
>>bean instance from within an interceptor.
>>
>>To test this (on Weld) I used the following code:
>>
>>@Interceptor
>>@DestroyOnError
>>@Priority(APPLICATION)
>>public class DestroyOnErrorInterceptor implements Serializable {
>>
>> private static final long serialVersionUID = 1L;
>>
>> @AroundInvoke
>> public Object tryInvoke(InvocationContext ctx) throws Exception {
>>
>> try {
>> return ctx.proceed();
>> } catch (Exception e) {
>> destroy(ctx.getMethod().getDeclaringClass());
>> throw e;
>> }
>> }
>>
>> private <T> void destroy(Class<T> clazz) {
>> Instance<T> instance = CDI.current().select(clazz);
>> instance.destroy(instance.get());
>> }
>>
>>}
>>
>>
>>When I use this interceptor on a SessionScoped bean:
>>
>>@SessionScoped
>>public class TestBean implements Serializable {
>>
>> private static final long serialVersionUID = 1L;
>>
>> @DestroyOnError
>> public void test() {
>> throw new IllegalStateException();
>> }
>>}
>>
>>And then inject said bean in say a Servlet and call the test() method,
>>destruction of the bean happens partially, but as soon as Weld tried
>>to invocate a preDestroy method, it goes through the bean proxy again,
>>detects that "the" interceptor handler is already active, promptly
>>skips its attempt to call a preDestroy method and then to add insult
>>to injury tries to call a "proceed" method which is always null and
>>thus throws a NPE.
>>
>>(this happens in
>>org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke)
>>
>>I tried some alternative methods to destroy the bean such as:
>>
>>
>>Bean<T> bean = resolve(beanManager, beanClass);
>>
>>AlterableContext context = (AlterableContext)
>>beanManager.getContext(bean.getScope());
>>context.destroy(bean);
>>
>>with resolve being:
>>
>>public static <T> Bean<T> resolve(BeanManager beanManager,
Class<T> beanClass) {
>> Set<Bean<?>> beans = beanManager.getBeans(beanClass);
>>
>> for (Bean<?> bean : beans) {
>> if (bean.getBeanClass() == beanClass) {
>> return (Bean<T>)
>>beanManager.resolve(Collections.<Bean<?>>singleton(bean));
>> }
>> }
>>
>> return (Bean<T>) beanManager.resolve(beans);
>> }
>>
>>But this resulted in the same problem.
>>
>>Any idea?
>>
>>Kind regards,
>>Arjan Tijms
>>_______________________________________________
>>cdi-dev mailing list
>>cdi-dev(a)lists.jboss.org
>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>Note that for all code provided on this list, the provider licenses the code under
the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all
other ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
>>
>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
3:46 a.m.
On 11/14/2014 09:14 AM, Mark Struberg wrote:
I did not say it cannot work but that it is not guaranteed to work.
It's just totally up to implementation details of the container and your actual
situation. Basically it's non-portable at best.
E.g. consider the case that you are NOT the outermost interceptor but there are 2 other
decorators and interceptors. The decorators will probably not hurt much as they are
defined to be called _after_ interceptors. But if there is an interceptor in addition to
yours then you will probably kill em and after returning from the chain you might end up
in a dead bean (the other interceptor).
You are right Mark but I think this is not a
problem of whether you call
AlterableContext.destroy() from within an interceptor or not. This is a
more general problem of destroying instances. Say you have an
intercepted @ApplicationScoped bean Foo. Thread 1 is calling an
intercepted method and is currently in the middle of the interceptor
chain. Thread 2 calls AlterableContext.destroy(Foo) in a Servlet (not
from an interceptor!). Foo is destroyed together with its interceptors
by Thread 2. Thread 1 finds itself executing a dead interceptor chain
for a destroyed bean.
There are just so many things which can go wrong. Even though I like the general idea
what you like to do with that interceptor. But I suggest you probably use another trick.
Every CDI bean must (as per the interceptors spec) support 'self-interception'.
Means you only need to add an @AroundInvoke method and do the re-setup of your CONNECTION
inside your @ApplicationScoped bean (with full access to the underlying business
infrastructure).
This is fundamentally different to your approach as I do not ditch the whole service but
only fix the thing which broke in it.
LieGrue,
strub
On Thursday, 13 November 2014, 16:28, arjan tijms <arjan.tijms(a)gmail.com> wrote:
> Hi,
>
> On Wednesday, November 12, 2014, Jozef Hartinger <jharting(a)redhat.com> wrote:
>
> Hi Arjan,
>> there is a bug in Weld (WELD-1785) preventing this from working which is going to
be fixed in the next release. What you are doing should work IMO as long as the
interceptor does not call any other methods on the target instance.
>
> That's great to hear really.
>
>
> I'm slightly confused through why Mark thinks this cannot really work, while you
say it should.
>
>
> Is there something in the spec that may need to be clarified here? Ie some words
about what an interceptor is at least allowed to do and what is definitely not allowed?
>
>
>
> In addition it must count with the target instance being destroyed within the
instance.destroy() call.
>
>
> Sorry, I don't fully follow this. You mean something must be counted?
>
>
>> Perhaps a nicer way of doing this would be:
>>
>> @Inject
>> @Intercepted
>> private Bean<?> bean;
>>
>> Context context = manager.getContext(bean.getScope());
>> if (!(context instanceof AlterableContext)) {
>> throw new IllegalStateException("Context does not support
removal of instances");
>> }
>> AlterableContext alterableContext =
AlterableContext.class.cast(context);
>> alterableContext.destroy(bean);
>
> I tried something close to that as well, just used the bean manager to resolve a Bean
from the target object. Thanks for the suggestion!
>
>
> Kind regards,
> Arjan
>
>
>
>
>> On 11/10/2014 02:59 PM, arjan tijms wrote:
>>
>> Hi,
>>> I wonder if it would be allowed according to the CDI spec to destroy a
>>> bean instance from within an interceptor.
>>>
>>> To test this (on Weld) I used the following code:
>>>
>>> @Interceptor
>>> @DestroyOnError
>>> @Priority(APPLICATION)
>>> public class DestroyOnErrorInterceptor implements Serializable {
>>>
>>> private static final long serialVersionUID = 1L;
>>>
>>> @AroundInvoke
>>> public Object tryInvoke(InvocationContext ctx) throws Exception {
>>>
>>> try {
>>> return ctx.proceed();
>>> } catch (Exception e) {
>>> destroy(ctx.getMethod().getDeclaringClass());
>>> throw e;
>>> }
>>> }
>>>
>>> private <T> void destroy(Class<T> clazz) {
>>> Instance<T> instance = CDI.current().select(clazz);
>>> instance.destroy(instance.get());
>>> }
>>>
>>> }
>>>
>>>
>>> When I use this interceptor on a SessionScoped bean:
>>>
>>> @SessionScoped
>>> public class TestBean implements Serializable {
>>>
>>> private static final long serialVersionUID = 1L;
>>>
>>> @DestroyOnError
>>> public void test() {
>>> throw new IllegalStateException();
>>> }
>>> }
>>>
>>> And then inject said bean in say a Servlet and call the test() method,
>>> destruction of the bean happens partially, but as soon as Weld tried
>>> to invocate a preDestroy method, it goes through the bean proxy again,
>>> detects that "the" interceptor handler is already active, promptly
>>> skips its attempt to call a preDestroy method and then to add insult
>>> to injury tries to call a "proceed" method which is always null
and
>>> thus throws a NPE.
>>>
>>> (this happens in
>>>
org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke)
>>>
>>> I tried some alternative methods to destroy the bean such as:
>>>
>>>
>>> Bean<T> bean = resolve(beanManager, beanClass);
>>>
>>> AlterableContext context = (AlterableContext)
>>> beanManager.getContext(bean.getScope());
>>> context.destroy(bean);
>>>
>>> with resolve being:
>>>
>>> public static <T> Bean<T> resolve(BeanManager beanManager,
Class<T> beanClass) {
>>> Set<Bean<?>> beans = beanManager.getBeans(beanClass);
>>>
>>> for (Bean<?> bean : beans) {
>>> if (bean.getBeanClass() == beanClass) {
>>> return (Bean<T>)
>>> beanManager.resolve(Collections.<Bean<?>>singleton(bean));
>>> }
>>> }
>>>
>>> return (Bean<T>) beanManager.resolve(beans);
>>> }
>>>
>>> But this resulted in the same problem.
>>>
>>> Any idea?
>>>
>>> Kind regards,
>>> Arjan Tijms
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the code
under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For
all other ideas provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
>>>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under
the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all
other ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
>
>
4:01 a.m.
I got your point Jozef, and I fear you are right. This is just pretty dangerous in highly
concurrent scenarios :/
LieGrue,
strub
On Friday, 14 November 2014, 10:47, Jozef Hartinger
<jharting(a)redhat.com> wrote:
>
On 11/14/2014 09:14 AM, Mark Struberg wrote:
> I did not say it cannot work but that it is not guaranteed to work.
It's just totally up to implementation details of the container and your
actual situation. Basically it's non-portable at best.
>
>
> E.g. consider the case that you are NOT the outermost interceptor but there
are 2 other decorators and interceptors. The decorators will probably not hurt
much as they are defined to be called _after_ interceptors. But if there is an
interceptor in addition to yours then you will probably kill em and after
returning from the chain you might end up in a dead bean (the other
interceptor).
You are right Mark but I think this is not a problem of whether you call
AlterableContext.destroy() from within an interceptor or not. This is a
more general problem of destroying instances. Say you have an
intercepted @ApplicationScoped bean Foo. Thread 1 is calling an
intercepted method and is currently in the middle of the interceptor
chain. Thread 2 calls AlterableContext.destroy(Foo) in a Servlet (not
from an interceptor!). Foo is destroyed together with its interceptors
by Thread 2. Thread 1 finds itself executing a dead interceptor chain
for a destroyed bean.
>
> There are just so many things which can go wrong. Even though I like the
general idea what you like to do with that interceptor. But I suggest you
probably use another trick. Every CDI bean must (as per the interceptors spec)
support 'self-interception'. Means you only need to add an @AroundInvoke
method and do the re-setup of your CONNECTION inside your @ApplicationScoped
bean (with full access to the underlying business infrastructure).
>
>
> This is fundamentally different to your approach as I do not ditch the
whole service but only fix the thing which broke in it.
>
>
> LieGrue,
> strub
>
>
>
> On Thursday, 13 November 2014, 16:28, arjan tijms
<arjan.tijms(a)gmail.com> wrote:
>> Hi,
>>
>> On Wednesday, November 12, 2014, Jozef Hartinger
<jharting(a)redhat.com> wrote:
>>
>> Hi Arjan,
>>> there is a bug in Weld (WELD-1785) preventing this from working
which is going to be fixed in the next release. What you are doing should work
IMO as long as the interceptor does not call any other methods on the target
instance.
>>
>> That's great to hear really.
>>
>>
>> I'm slightly confused through why Mark thinks this cannot really
work, while you say it should.
>>
>>
>> Is there something in the spec that may need to be clarified here? Ie
some words about what an interceptor is at least allowed to do and what is
definitely not allowed?
>>
>>
>>
>> In addition it must count with the target instance being destroyed
within the instance.destroy() call.
>>
>>
>> Sorry, I don't fully follow this. You mean something must be
counted?
>>
>>
>>> Perhaps a nicer way of doing this would be:
>>>
>>> @Inject
>>> @Intercepted
>>> private Bean<?> bean;
>>>
>>> Context context = manager.getContext(bean.getScope());
>>> if (!(context instanceof AlterableContext)) {
>>> throw new IllegalStateException("Context does not
support removal of instances");
>>> }
>>> AlterableContext alterableContext =
AlterableContext.class.cast(context);
>>> alterableContext.destroy(bean);
>>
>> I tried something close to that as well, just used the bean manager to
resolve a Bean from the target object. Thanks for the suggestion!
>>
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>>> On 11/10/2014 02:59 PM, arjan tijms wrote:
>>>
>>> Hi,
>>>> I wonder if it would be allowed according to the CDI spec to
destroy a
>>>> bean instance from within an interceptor.
>>>>
>>>> To test this (on Weld) I used the following code:
>>>>
>>>> @Interceptor
>>>> @DestroyOnError
>>>> @Priority(APPLICATION)
>>>> public class DestroyOnErrorInterceptor implements Serializable
{
>>>>
>>>> private static final long serialVersionUID = 1L;
>>>>
>>>> @AroundInvoke
>>>> public Object tryInvoke(InvocationContext ctx) throws
Exception {
>>>>
>>>> try {
>>>> return ctx.proceed();
>>>> } catch (Exception e) {
>>>> destroy(ctx.getMethod().getDeclaringClass());
>>>> throw e;
>>>> }
>>>> }
>>>>
>>>> private <T> void destroy(Class<T> clazz)
{
>>>> Instance<T> instance =
CDI.current().select(clazz);
>>>> instance.destroy(instance.get());
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>> When I use this interceptor on a SessionScoped bean:
>>>>
>>>> @SessionScoped
>>>> public class TestBean implements Serializable {
>>>>
>>>> private static final long serialVersionUID = 1L;
>>>>
>>>> @DestroyOnError
>>>> public void test() {
>>>> throw new IllegalStateException();
>>>> }
>>>> }
>>>>
>>>> And then inject said bean in say a Servlet and call the test()
method,
>>>> destruction of the bean happens partially, but as soon as Weld
tried
>>>> to invocate a preDestroy method, it goes through the bean proxy
again,
>>>> detects that "the" interceptor handler is already
active, promptly
>>>> skips its attempt to call a preDestroy method and then to add
insult
>>>> to injury tries to call a "proceed" method which is
always null and
>>>> thus throws a NPE.
>>>>
>>>> (this happens in
>>>>
org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke)
>>>>
>>>> I tried some alternative methods to destroy the bean such as:
>>>>
>>>>
>>>> Bean<T> bean = resolve(beanManager, beanClass);
>>>>
>>>> AlterableContext context = (AlterableContext)
>>>> beanManager.getContext(bean.getScope());
>>>> context.destroy(bean);
>>>>
>>>> with resolve being:
>>>>
>>>> public static <T> Bean<T> resolve(BeanManager
beanManager, Class<T> beanClass) {
>>>> Set<Bean<?>> beans =
beanManager.getBeans(beanClass);
>>>>
>>>> for (Bean<?> bean : beans) {
>>>> if (bean.getBeanClass() == beanClass) {
>>>> return (Bean<T>)
>>>>
beanManager.resolve(Collections.<Bean<?>>singleton(bean));
>>>> }
>>>> }
>>>>
>>>> return (Bean<T>) beanManager.resolve(beans);
>>>> }
>>>>
>>>> But this resulted in the same problem.
>>>>
>>>> Any idea?
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider
licenses the code under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
on this list, the provider waives all patent and other intellectual property
rights inherent in such information.
>>>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
on this list, the provider waives all patent and other intellectual property
rights inherent in such information.
>>
>>
10:27 a.m.
Hi,
On Friday, November 14, 2014, Jozef Hartinger <jharting(a)redhat.com
<javascript:_e(%7B%7D,'cvml','jharting@redhat.com');>> wrote:
On 11/14/2014 09:14 AM, Mark Struberg wrote:
> I did not say it cannot work but that it is not guaranteed to work. It's
> just totally up to implementation details of the container and your actual
> situation. Basically it's non-portable at best.
>
>
> E.g. consider the case that you are NOT the outermost interceptor but
> there are 2 other decorators and interceptors. The decorators will probably
> not hurt much as they are defined to be called _after_ interceptors. But if
> there is an interceptor in addition to yours then you will probably kill em
> and after returning from the chain you might end up in a dead bean (the
> other interceptor).
>
You are right Mark but I think this is not a problem of whether you call
AlterableContext.destroy() from within an interceptor or not. This is a
more general problem of destroying instances. Say you have an intercepted
@ApplicationScoped bean Foo. Thread 1 is calling an intercepted method and
is currently in the middle of the interceptor chain. Thread 2 calls
AlterableContext.destroy(Foo) in a Servlet (not from an interceptor!). Foo
is destroyed together with its interceptors by Thread 2. Thread 1 finds
itself executing a dead interceptor chain for a destroyed bean.
It looks like the issue may be even more general.
I have to do some more tests to confirm, but I think I observed a situation
where thread 1 at the end of a request destroyed session scoped bean Foo in
a Servlet. At that point thread 2 was already using bean Foo, and it kept
getting the same instance from the proxy and could even destroy the bean
again. Meanwhile, while thread 2 was getting the destroyed bean instance,
thread 3 that started after the instance was destroyed by thread 1 did get
a new instance.
It looked like some TLS caching issue, but as said I have to do some more
tests to see if this can be reproduced.
Kind regards,
Arjan Tijms
> There are just so many things which can go wrong. Even though I
like the
> general idea what you like to do with that interceptor. But I suggest you
> probably use another trick. Every CDI bean must (as per the interceptors
> spec) support 'self-interception'. Means you only need to add an
> @AroundInvoke method and do the re-setup of your CONNECTION inside your
> @ApplicationScoped bean (with full access to the underlying business
> infrastructure).
>
>
> This is fundamentally different to your approach as I do not ditch the
> whole service but only fix the thing which broke in it.
>
>
> LieGrue,
> strub
>
>
>
> On Thursday, 13 November 2014, 16:28, arjan tijms <arjan.tijms(a)gmail.com>
> wrote:
>
>> Hi,
>>
>> On Wednesday, November 12, 2014, Jozef Hartinger <jharting(a)redhat.com>
>> wrote:
>>
>> Hi Arjan,
>>
>>> there is a bug in Weld (WELD-1785) preventing this from working which
>>> is going to be fixed in the next release. What you are doing should work
>>> IMO as long as the interceptor does not call any other methods on the
>>> target instance.
>>>
>>
>> That's great to hear really.
>>
>>
>> I'm slightly confused through why Mark thinks this cannot really work,
>> while you say it should.
>>
>>
>> Is there something in the spec that may need to be clarified here? Ie
>> some words about what an interceptor is at least allowed to do and what is
>> definitely not allowed?
>>
>>
>>
>> In addition it must count with the target instance being destroyed
>> within the instance.destroy() call.
>>
>>
>> Sorry, I don't fully follow this. You mean something must be counted?
>>
>>
>> Perhaps a nicer way of doing this would be:
>>>
>>> @Inject
>>> @Intercepted
>>> private Bean<?> bean;
>>>
>>> Context context = manager.getContext(bean.getScope());
>>> if (!(context instanceof AlterableContext)) {
>>> throw new IllegalStateException("Context does not support
>>> removal of instances");
>>> }
>>> AlterableContext alterableContext = AlterableContext.class.cast(
>>> context);
>>> alterableContext.destroy(bean);
>>>
>>
>> I tried something close to that as well, just used the bean manager to
>> resolve a Bean from the target object. Thanks for the suggestion!
>>
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>> On 11/10/2014 02:59 PM, arjan tijms wrote:
>>>
>>> Hi,
>>>
>>>> I wonder if it would be allowed according to the CDI spec to destroy a
>>>> bean instance from within an interceptor.
>>>>
>>>> To test this (on Weld) I used the following code:
>>>>
>>>> @Interceptor
>>>> @DestroyOnError
>>>> @Priority(APPLICATION)
>>>> public class DestroyOnErrorInterceptor implements Serializable {
>>>>
>>>> private static final long serialVersionUID = 1L;
>>>>
>>>> @AroundInvoke
>>>> public Object tryInvoke(InvocationContext ctx) throws Exception {
>>>>
>>>> try {
>>>> return ctx.proceed();
>>>> } catch (Exception e) {
>>>> destroy(ctx.getMethod().getDeclaringClass());
>>>> throw e;
>>>> }
>>>> }
>>>>
>>>> private <T> void destroy(Class<T> clazz) {
>>>> Instance<T> instance = CDI.current().select(clazz);
>>>> instance.destroy(instance.get());
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>> When I use this interceptor on a SessionScoped bean:
>>>>
>>>> @SessionScoped
>>>> public class TestBean implements Serializable {
>>>>
>>>> private static final long serialVersionUID = 1L;
>>>>
>>>> @DestroyOnError
>>>> public void test() {
>>>> throw new IllegalStateException();
>>>> }
>>>> }
>>>>
>>>> And then inject said bean in say a Servlet and call the test() method,
>>>> destruction of the bean happens partially, but as soon as Weld tried
>>>> to invocate a preDestroy method, it goes through the bean proxy again,
>>>> detects that "the" interceptor handler is already active,
promptly
>>>> skips its attempt to call a preDestroy method and then to add insult
>>>> to injury tries to call a "proceed" method which is always null
and
>>>> thus throws a NPE.
>>>>
>>>> (this happens in
>>>> org.jboss.weld.bean.proxy.CombinedInterceptorAndDecorato
>>>> rStackMethodHandler.invoke)
>>>>
>>>> I tried some alternative methods to destroy the bean such as:
>>>>
>>>>
>>>> Bean<T> bean = resolve(beanManager, beanClass);
>>>>
>>>> AlterableContext context = (AlterableContext)
>>>> beanManager.getContext(bean.getScope());
>>>> context.destroy(bean);
>>>>
>>>> with resolve being:
>>>>
>>>> public static <T> Bean<T> resolve(BeanManager beanManager,
Class<T>
>>>> beanClass) {
>>>> Set<Bean<?>> beans =
beanManager.getBeans(beanClass);
>>>>
>>>> for (Bean<?> bean : beans) {
>>>> if (bean.getBeanClass() == beanClass) {
>>>> return (Bean<T>)
>>>> beanManager.resolve(Collections.<Bean<?>>singleton(bean));
>>>> }
>>>> }
>>>>
>>>> return (Bean<T>) beanManager.resolve(beans);
>>>> }
>>>>
>>>> But this resulted in the same problem.
>>>>
>>>> Any idea?
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses
>>>> the code under the Apache License, Version 2 (http://www.apache.org/
>>>> licenses/LICENSE-2.0.html). For all other ideas provided on this
>>>> list, the provider waives all patent and other intellectual property
rights
>>>> inherent in such information.
>>>>
>>>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (http://www.apache.org/
>> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
>> the provider waives all patent and other intellectual property rights
>> inherent in such information.
>>
>>
>>
3:49 a.m.
On 11/13/2014 04:27 PM, arjan tijms wrote:
Hi,
On Wednesday, November 12, 2014, Jozef Hartinger <jharting(a)redhat.com
<mailto:jharting@redhat.com>> wrote:
Hi Arjan,
there is a bug in Weld (WELD-1785) preventing this from working
which is going to be fixed in the next release. What you are doing
should work IMO as long as the interceptor does not call any other
methods on the target instance.
That's great to hear really.
I'm slightly confused through why Mark thinks this cannot really work,
while you say it should.
Don't be confused by that. This often happens to me
and Mark :-)
Is there something in the spec that may need to be clarified here? Ie
some words about what an interceptor is at least allowed to do and
what is definitely not allowed?
In addition it must count with the target instance being destroyed
within the instance.destroy() call.
Sorry, I don't fully follow this. You mean something must be counted?
I mean
that the interceptor (and others in the chain) should be tolerant
and not be surprised finding itself and the target bean destroyed
immediately after the instance.destroy() call.
Perhaps a nicer way of doing this would be:
@Inject
@Intercepted
private Bean<?> bean;
Context context = manager.getContext(bean.getScope());
if (!(context instanceof AlterableContext)) {
throw new IllegalStateException("Context does not
support removal of instances");
}
AlterableContext alterableContext =
AlterableContext.class.cast(context);
alterableContext.destroy(bean);
I tried something close to that as well, just used the bean manager to
resolve a Bean from the target object. Thanks for the suggestion!
Kind regards,
Arjan
On 11/10/2014 02:59 PM, arjan tijms wrote:
Hi,
I wonder if it would be allowed according to the CDI spec to
destroy a
bean instance from within an interceptor.
To test this (on Weld) I used the following code:
@Interceptor
@DestroyOnError
@Priority(APPLICATION)
public class DestroyOnErrorInterceptor implements Serializable {
private static final long serialVersionUID = 1L;
@AroundInvoke
public Object tryInvoke(InvocationContext ctx) throws
Exception {
try {
return ctx.proceed();
} catch (Exception e) {
destroy(ctx.getMethod().getDeclaringClass());
throw e;
}
}
private <T> void destroy(Class<T> clazz) {
Instance<T> instance = CDI.current().select(clazz);
instance.destroy(instance.get());
}
}
When I use this interceptor on a SessionScoped bean:
@SessionScoped
public class TestBean implements Serializable {
private static final long serialVersionUID = 1L;
@DestroyOnError
public void test() {
throw new IllegalStateException();
}
}
And then inject said bean in say a Servlet and call the test()
method,
destruction of the bean happens partially, but as soon as Weld
tried
to invocate a preDestroy method, it goes through the bean
proxy again,
detects that "the" interceptor handler is already active, promptly
skips its attempt to call a preDestroy method and then to add
insult
to injury tries to call a "proceed" method which is always
null and
thus throws a NPE.
(this happens in
org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke)
I tried some alternative methods to destroy the bean such as:
Bean<T> bean = resolve(beanManager, beanClass);
AlterableContext context = (AlterableContext)
beanManager.getContext(bean.getScope());
context.destroy(bean);
with resolve being:
public static <T> Bean<T> resolve(BeanManager beanManager,
Class<T> beanClass) {
Set<Bean<?>> beans = beanManager.getBeans(beanClass);
for (Bean<?> bean : beans) {
if (bean.getBeanClass() == beanClass) {
return (Bean<T>)
beanManager.resolve(Collections.<Bean<?>>singleton(bean));
}
}
return (Bean<T>) beanManager.resolve(beans);
}
But this resulted in the same problem.
Any idea?
Kind regards,
Arjan Tijms
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider
licenses the code under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all
other ideas provided on this list, the provider waives all
patent and other intellectual property rights inherent in such
information.
4228
days inactive
4232
days old
10 comments
3 participants
participants (3)
-
arjan tijms -
Jozef Hartinger -
Mark Struberg