[
https://issues.apache.org/jira/browse/EXTCDI-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Korherr resolved EXTCDI-71.
---------------------------------
Resolution: Fixed
Fix Version/s: 1.0.0-SNAPSHOT
> ClassDeactivator configuration via JNDI
> ---------------------------------------
>
> Key: EXTCDI-71
> URL: https://issues.apache.org/jira/browse/EXTCDI-71
> Project: MyFaces CODI
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.0.0-SNAPSHOT
> Reporter: Jakob Korherr
> Assignee: Jakob Korherr
> Fix For: 1.0.0-SNAPSHOT
>
>
> Currently it is only possible to set the ClassDeactivator via a system
> property, but this can be a problem in some scenarios (webapps, test cases,
> ...). Thus there should be another way to define the ClassDeactivator.
> The problem is that this information needs to be available very early in the
> application lifecycle, even before CDI initializes, thus it could be solved
> via a web.xml init parameter. However this introduces another problem: how to
> get the reference to the ServletContext to get the init parameter in the
> first place.
> This means we must use some other type of configuration, a custom xml config
> file or JNDI. Because of the fact that all major containers provide JNDI and
> it can also be set via web.xml (env-entry), we agreed to use JNDI for this.
> Example:
> <env-entry>
> <env-entry-name>myfaces-codi/ClassDeactivator</env-entry-name>
> <env-entry-type>java.lang.String</env-entry-type>
>
> <env-entry-value>org.apache.myfaces.extensions.cdi.test.webapp.scopemapping.deactivator.ScopeMappingDeactivator</env-entry-value>
> </env-entry>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
