[
https://issues.jboss.org/browse/WELD-883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671848#comment-12671848
]
Ales Justin commented on WELD-883:
----------------------------------
Is this still an issue with the latest Weld 1.1.5.Final?
> 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.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_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 [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())
> >> Despite the fact the Context is in an EJB module whilst its Extension
> >> configuration is in another jar of the same EAR, the bean is correctly
> >> destroyed and re-produced: it works !!
> 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).
--
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
_______________________________________________
weld-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-issues
