[
https://issues.jboss.org/browse/WELD-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fab Mars updated WELD-883:
--------------------------
Attachment: weld_context_destroy_bean_issue (ext config, decl config).zip
Use case 1
> Weird behavior of custom context in some configurations
> -------------------------------------------------------
>
> Key: WELD-883
> URL: https://issues.jboss.org/browse/WELD-883
> Project: Weld
> Issue Type: Bug
> Components: Scopes & Contexts
> Affects Versions: 1.1.1.Final
> Environment: W7 x86, Glassfish 3.1 GA, Weld 1.1.1, JDK 1.6.0_24
> Reporter: Fab Mars
> Labels: context, custom, extension, scope
> Attachments: 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 rom 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 (whichtherefore will 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 jar won't deploy, error WELD001324
> 3) Now let's move back the extension configuration 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 rom 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 (whichtherefore will be reloaded on the next get())
> >> Despite the fact the Context is in an EJB module whilst its Extension
> >> configuration is in another jar of the same EAR, it works !!
> I'm not storng 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
weld-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-issues
