[weld-issues] [JBoss JIRA] (WELD-883) Weird behavior of custom context in some configurations in an EAR

[ https://issues.jboss.org/browse/WELD-883?page=com.atlassian.jira.plugin.s... ] Fab Mars updated WELD-883: -------------------------- Affects Version/s: 1.1.5.Final (was: 1.1.1.Final) Environment: W7 x86, Glassfish 3.1.2b23, Weld 1.1.5, JDK 1.6.0_29 (was: W7 x86, Glassfish 3.1 GA, Weld 1.1.1, JDK 1.6.0_24) Description: In my applciation, some configs are in external xml files. They may be updated by hand and configs reloaded on the fly. While migrating to CDI, the methods loading the confg became producers and the beans holding the config became @ApplicationScoped. I couldn't reload configs anymore, so I created a custom scope to control the lifecycle of my configs. And I faced a couple of issues. My EAR is a good old one: some api jar (TrucEJBClient), the business logic module (TrucEBJ), the tools and config stuff jar (TrucConfig) and the web module (TrucWeb). 1) At first I obviously put the new scope and context in the TrucConfig jar. Open weld_context_destroy_bean_issue (ext config, decl config).zip and deploy the ear. Test via http://localhost:8080/TrucWeb/test.jsf , the text displayed comes from 2 bean instances generated with producer methods from xml files Click on the button [alter configs], one of the 2 beans is modified on the fly. Then click on the button [reset configs] which triggers an event to destroy the aforementioned bean (that's supposed to be be reloaded on the next get()) Problem: As you can see the bean isn't destroyed. If you have a look at com.dummy.config.ConfigContext line 106, you can see beanManager.getBeans(instance.getClass(), xmlConfigQualifier) returns an empty set. However you can also see contextualInstancesMap.size() == 2, so I'm not able to retrieve my beans correctly there. 2) Now let's move the context and its extension configuration javax.enterprise.inject.spi.Extension into the TrucEJB module. Open weld_error_001324 (ext ejb, decl ejb).zip and deploy the jar The EAR won't deploy, error WELD001324 3) Now let's move the extension configuration (not the context/extension themselves) back into the TrucConfig jar. Open weld_working (ext ejb, decl config).zip and deploy the ear. Test via http://localhost:8080/TrucWeb/test.jsf , the text displayed comes from 2 bean instances generated with producer methods from xml files Click on the button [alter configs], one of the 2 beans is modified on the fly. Then click on the button [reset configs] which triggers an event to destroy the aforementioned bean (that's supposed to be reloaded on the next get()) I found this workaround by chance. I'm not strong enough yet with the Weld code, so it's hard for me to find the root cause(s). was: In my applciation, some configs are in external xml files. They may be updated by hand and configs reloaded on the fly. While migrating to CDI, the methods loading the confg became producers and the beans holding the config became @ApplicationScoped. I couldn't reload configs anymore, so I created a custom scope to control the lifecycle of my configs. And I faced a couple of issues. My EAR is a good old one: some api jar (TrucEJBClient), the business logic module (TrucEBJ), the tools and config stuff jar (TrucConfig) and the web module (TrucWeb). 1) At first I obviously put the new scope and context in the TrucConfig jar. Open weld_context_destroy_bean_issue (ext config, decl config).zip and deploy the ear. Test via http://localhost:8080/TrucWeb/test.jsf , the text displayed comes from 2 bean instances generated with producer methods from xml files Click on the button [alter configs], one of the 2 beans is modified on the fly. Then click on the button [reload configs] which triggers an event to destroy the aforementioned bean (that's supposed to be be reloaded on the next get()) Problem: As you can see the bean isn't destroyed. If you have a look at com.dummy.config.ConfigContext line 106, you can see beanManager.getBeans(instance.getClass(), xmlConfigQualifier) returns an empty set. However you can also see contextualInstancesMap.size() == 2, so I'm not able to retrieve my beans correctly there. 2) Now let's move the context and its extension configuration javax.enterprise.inject.spi.Extension into the TrucEJB module. Open weld_error_001324 (ext ejb, decl ejb).zip and deploy the jar The EAR won't deploy, error WELD001324 3) Now let's move the extension configuration (not the context/extension themselves) back into the TrucConfig jar. Open weld_working (ext ejb, decl config).zip and deploy the ear. Test via http://localhost:8080/TrucWeb/test.jsf , the text displayed comes from 2 bean instances generated with producer methods from xml files Click on the button [alter configs], one of the 2 beans is modified on the fly. Then click on the button [reload configs] which triggers an event to destroy the aforementioned bean (that's supposed to be reloaded on the next get()) I found this workaround by chance. I'm not storng enough yet with the Weld code, so it's hard for me to find the root cause(s). > Weird behavior of custom context in some configurations in an EAR > ----------------------------------------------------------------- > > Key: WELD-883 > URL: https://issues.jboss.org/browse/WELD-883 > Project: Weld > Issue Type: Bug > Components: Scopes & Contexts > Affects Versions: 1.1.5.Final > Environment: W7 x86, Glassfish 3.1.2b23, Weld 1.1.5, JDK 1.6.0_29 > Reporter: Fab Mars > Labels: context, custom, extension, scope > Attachments: weld_context_destroy_bean_issue (ext config, decl config).zip, weld_context_destroy_bean_issue (ext config, decl config).zip, weld_error_001324 (ext ejb, decl ejb).zip, weld_working (ext ejb, decl config).zip > > > In my applciation, some configs are in external xml files. They may be updated by hand and configs reloaded on the fly. While migrating to CDI, the methods loading the confg became producers and the beans holding the config became @ApplicationScoped. > I couldn't reload configs anymore, so I created a custom scope to control the lifecycle of my configs. And I faced a couple of issues. > My EAR is a good old one: some api jar (TrucEJBClient), the business logic module (TrucEBJ), the tools and config stuff jar (TrucConfig) and the web module (TrucWeb). > 1) At first I obviously put the new scope and context in the TrucConfig jar. > Open weld_context_destroy_bean_issue (ext config, decl config).zip and deploy the ear. > Test via http://localhost:8080/TrucWeb/test.jsf , the text displayed comes from 2 bean instances generated with producer methods from xml files > Click on the button [alter configs], one of the 2 beans is modified on the fly. > Then click on the button [reset configs] which triggers an event to destroy the aforementioned bean (that's supposed to be be reloaded on the next get()) > Problem: As you can see the bean isn't destroyed. > If you have a look at com.dummy.config.ConfigContext line 106, you can see beanManager.getBeans(instance.getClass(), xmlConfigQualifier) returns an empty set. > However you can also see contextualInstancesMap.size() == 2, so I'm not able to retrieve my beans correctly there. > 2) Now let's move the context and its extension configuration javax.enterprise.inject.spi.Extension into the TrucEJB module. > Open weld_error_001324 (ext ejb, decl ejb).zip and deploy the jar > The EAR won't deploy, error WELD001324 > 3) Now let's move the extension configuration (not the context/extension themselves) back into the TrucConfig jar. > Open weld_working (ext ejb, decl config).zip and deploy the ear. > Test via http://localhost:8080/TrucWeb/test.jsf , the text displayed comes from 2 bean instances generated with producer methods from xml files > Click on the button [alter configs], one of the 2 beans is modified on the fly. > Then click on the button [reset configs] which triggers an event to destroy the aforementioned bean (that's supposed to be reloaded on the next get()) > > I found this workaround by chance. > I'm not strong enough yet with the Weld code, so it's hard for me to find the root cause(s). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira