February 2019 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-743) NPE when trying to get BeanManager after container was closed

by Doychin Bondzhev (Jira)

[ https://issues.jboss.org/browse/CDI-743?page=com.atlassian.jira.plugin.sy... ] Doychin Bondzhev edited comment on CDI-743 at 2/15/19 10:06 AM: ---------------------------------------------------------------- This was the first thing I implemented. I will open PR with my change for discussion. But this PR relies on the fact that null is valid return value for {{getCDI}} was (Author: doychin): This was the first thing I implemented. I will open PR with my change for discussion. > NPE when trying to get BeanManager after container was closed > ------------------------------------------------------------- > > Key: CDI-743 > URL: https://issues.jboss.org/browse/CDI-743 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0 .Final, 2.0.SP1 > Environment: simple application that uses weld-se-core and cdi api. > Reporter: Doychin Bondzhev > Priority: Major > > CDI.current() should produce IllegalStateException when there is no active container at the moment. > Instead on the second call in the sample application CDI.current() returns null and that results in NPE. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-743) NPE when trying to get BeanManager after container was closed

by Doychin Bondzhev (Jira)

[ https://issues.jboss.org/browse/CDI-743?page=com.atlassian.jira.plugin.sy... ] Doychin Bondzhev updated CDI-743: --------------------------------- Git Pull Request: https://github.com/cdi-spec/cdi/pull/394 > NPE when trying to get BeanManager after container was closed > ------------------------------------------------------------- > > Key: CDI-743 > URL: https://issues.jboss.org/browse/CDI-743 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0 .Final, 2.0.SP1 > Environment: simple application that uses weld-se-core and cdi api. > Reporter: Doychin Bondzhev > Priority: Major > > CDI.current() should produce IllegalStateException when there is no active container at the moment. > Instead on the second call in the sample application CDI.current() returns null and that results in NPE. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-743) NPE when trying to get BeanManager after container was closed

by Doychin Bondzhev (Jira)

[ https://issues.jboss.org/browse/CDI-743?page=com.atlassian.jira.plugin.sy... ] Doychin Bondzhev commented on CDI-743: -------------------------------------- This was the first thing I implemented. I will open PR with my change for discussion. > NPE when trying to get BeanManager after container was closed > ------------------------------------------------------------- > > Key: CDI-743 > URL: https://issues.jboss.org/browse/CDI-743 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0 .Final, 2.0.SP1 > Environment: simple application that uses weld-se-core and cdi api. > Reporter: Doychin Bondzhev > Priority: Major > > CDI.current() should produce IllegalStateException when there is no active container at the moment. > Instead on the second call in the sample application CDI.current() returns null and that results in NPE. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-743) NPE when trying to get BeanManager after container was closed

by Matej Novotny (Jira)

[ https://issues.jboss.org/browse/CDI-743?page=com.atlassian.jira.plugin.sy... ] Matej Novotny edited comment on CDI-743 at 2/15/19 9:42 AM: ------------------------------------------------------------ Actually, I think that {{getCDIProvider()}} method should probably check upon every access that the chosen provider (even the cached one) still returns non-null value from {{getCDI()}}. That, or better still, it should catch ISE from the invocation of {{getCDI()}} because currently it doesn't take into consideration that providers would do that despite the fact that {{getCDI()}} contract clearly states ISE as a valid "return" option. Imagine a situation with multiple CDI providers and you read Weld's one first and since no Weld container runs at the moment, it blows up with ISE. Now what{{CDI}} does is that it stops iterating over all providers and proliferates this exception to you effectively hiding remaining CDI providers that could have worked. was (Author: manovotn): Actually, I think that {{getCDIProvider()}} method should probably check upon every access that the chosen provider (even the cached one) still returns non-null value from {{getCDI()}}. That, or it should catch ISE from the invocation of {{getCDI()}} because currently it doesn't take into consideration that providers would do that. Imagine a situation with multiple CDI providers and you read Weld's one first and since no Weld container runs at the moment, it blows up with ISE. Now what{{CDI}} does is that it stops iterating over all providers and proliferates this exception to you. > NPE when trying to get BeanManager after container was closed > ------------------------------------------------------------- > > Key: CDI-743 > URL: https://issues.jboss.org/browse/CDI-743 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0 .Final, 2.0.SP1 > Environment: simple application that uses weld-se-core and cdi api. > Reporter: Doychin Bondzhev > Priority: Major > > CDI.current() should produce IllegalStateException when there is no active container at the moment. > Instead on the second call in the sample application CDI.current() returns null and that results in NPE. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-743) NPE when trying to get BeanManager after container was closed

by Matej Novotny (Jira)

[ https://issues.jboss.org/browse/CDI-743?page=com.atlassian.jira.plugin.sy... ] Matej Novotny commented on CDI-743: ----------------------------------- Actually, I think that {{getCDIProvider()}} method should probably check upon every access that the chosen provider (even the cached one) still returns non-null value from {{getCDI()}}. That, or it should catch ISE from the invocation of {{getCDI()}} because currently it doesn't take into consideration that providers would do that. Imagine a situation with multiple CDI providers and you read Weld's one first and since no Weld container runs at the moment, it blows up with ISE. Now what{{CDI}} does is that it stops iterating over all providers and proliferates this exception to you. > NPE when trying to get BeanManager after container was closed > ------------------------------------------------------------- > > Key: CDI-743 > URL: https://issues.jboss.org/browse/CDI-743 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0 .Final, 2.0.SP1 > Environment: simple application that uses weld-se-core and cdi api. > Reporter: Doychin Bondzhev > Priority: Major > > CDI.current() should produce IllegalStateException when there is no active container at the moment. > Instead on the second call in the sample application CDI.current() returns null and that results in NPE. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-743) NPE when trying to get BeanManager after container was closed

by Matej Novotny (Jira)

[ https://issues.jboss.org/browse/CDI-743?page=com.atlassian.jira.plugin.sy... ] Matej Novotny updated CDI-743: ------------------------------ Steps to Reproduce: Try to run this application: {code} import javax.enterprise.inject.se.SeContainer; import javax.enterprise.inject.se.SeContainerInitializer; import javax.enterprise.inject.spi.CDI; public class NPEOnSecondGetBeanManager { public static void main(String[] args) { SeContainer container = SeContainerInitializer.newInstance() .disableDiscovery() .addBeanClasses(BeanClass.class) .initialize(); CDI.current().getBeanManager(); container.close(); CDI.current().getBeanManager(); } public static class BeanClass { } } {code} was: Try to run this application: import javax.enterprise.inject.se.SeContainer; import javax.enterprise.inject.se.SeContainerInitializer; import javax.enterprise.inject.spi.CDI; public class NPEOnSecondGetBeanManager { public static void main(String[] args) { SeContainer container = SeContainerInitializer.newInstance() .disableDiscovery() .addBeanClasses(BeanClass.class) .initialize(); CDI.current().getBeanManager(); container.close(); CDI.current().getBeanManager(); } public static class BeanClass { } } > NPE when trying to get BeanManager after container was closed > ------------------------------------------------------------- > > Key: CDI-743 > URL: https://issues.jboss.org/browse/CDI-743 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0 .Final, 2.0.SP1 > Environment: simple application that uses weld-se-core and cdi api. > Reporter: Doychin Bondzhev > Priority: Major > > CDI.current() should produce IllegalStateException when there is no active container at the moment. > Instead on the second call in the sample application CDI.current() returns null and that results in NPE. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-743) NPE when trying to get BeanManager after container was closed

by Doychin Bondzhev (Jira)

[ https://issues.jboss.org/browse/CDI-743?page=com.atlassian.jira.plugin.sy... ] Doychin Bondzhev commented on CDI-743: -------------------------------------- Please close this issue. I will open it against weld. > NPE when trying to get BeanManager after container was closed > ------------------------------------------------------------- > > Key: CDI-743 > URL: https://issues.jboss.org/browse/CDI-743 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0 .Final, 2.0.SP1 > Environment: simple application that uses weld-se-core and cdi api. > Reporter: Doychin Bondzhev > Priority: Major > > CDI.current() should produce IllegalStateException when there is no active container at the moment. > Instead on the second call in the sample application CDI.current() returns null and that results in NPE. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-743) NPE when trying to get BeanManager after container was closed

by Doychin Bondzhev (Jira)

[ https://issues.jboss.org/browse/CDI-743?page=com.atlassian.jira.plugin.sy... ] Doychin Bondzhev commented on CDI-743: -------------------------------------- Looks like the source of the problem is incorrect implementation in Weld for getCDI method. It should not return null. Instead it should throw IllegalStateException > NPE when trying to get BeanManager after container was closed > ------------------------------------------------------------- > > Key: CDI-743 > URL: https://issues.jboss.org/browse/CDI-743 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0 .Final, 2.0.SP1 > Environment: simple application that uses weld-se-core and cdi api. > Reporter: Doychin Bondzhev > Priority: Major > > CDI.current() should produce IllegalStateException when there is no active container at the moment. > Instead on the second call in the sample application CDI.current() returns null and that results in NPE. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-743) NPE when trying to get BeanManager after container was closed

by Doychin Bondzhev (Jira)

Doychin Bondzhev created CDI-743: ------------------------------------ Summary: NPE when trying to get BeanManager after container was closed Key: CDI-743 URL: https://issues.jboss.org/browse/CDI-743 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 2.0.SP1, 2.0 .Final Environment: simple application that uses weld-se-core and cdi api. Reporter: Doychin Bondzhev CDI.current() should produce IllegalStateException when there is no active container at the moment. Instead on the second call in the sample application CDI.current() returns null and that results in NPE. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter

by Matej Novotny (Jira)

[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ] Matej Novotny commented on CDI-686: ----------------------------------- I have taken a stab at this with Weld 3.1.0.Final and managed to come up with a working prototype that can base {{InterceptionFactory}} off an interface while providing even unproxyable instance in the end. So it's definitely possible yet comes with many question marks attached. Here are some from the top of my head with my thoughts on them: * What about the interceptor binding(s) on the implementation class? Do you retain them or toss them away? ** IMO toss away, since it can be unproxyable, there is no reason to have them there in the first place * What about binding on interface itself? ** There is a possibility that the interface has some bindings, but CDI disregards annotations on interfaces in general, I would do the same here ** Accepting those would also introduce a problem of clashes in values if you try to programatically add the same annotation that is already present on the interface * What about hierarchies of interfaces - what if I add a class-level binding programatically, does it apply to methods from this interface's predecessors that weren't overriden? ** Here I honestly don't know, I went with _no_ in the first draft just because it required extra magic to make that happen and it's a corner case > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Priority: Major > Fix For: 2.0 .Final > > > If you take this code: > {code:java} > @Produces > public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2019