[
https://issues.apache.org/jira/browse/MYFACES-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-2928.
-------------------------------------
Fix Version/s: 1.1.9-SNAPSHOT
1.2.10-SNAPSHOT
2.0.3-SNAPSHOT
Resolution: Fixed
> FacesConfigurator cast for ApplicationImpl directly to load converter
> configuration, instead use RuntimeConfig object
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: MYFACES-2928
> URL: https://issues.apache.org/jira/browse/MYFACES-2928
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Affects Versions: 1.1.9-SNAPSHOT, 1.2.10-SNAPSHOT, 2.0.3-SNAPSHOT
> Reporter: Leonardo Uribe
> Assignee: Leonardo Uribe
> Fix For: 1.1.9-SNAPSHOT, 1.2.10-SNAPSHOT, 2.0.3-SNAPSHOT
>
>
> Checking some code on myfaces I notice this lines on FacesConfigurator:
> if(application instanceof ApplicationImpl)
> {
> for (Iterator it =
> _dispenser.getConverterConfigurationByClassName(); it.hasNext();)
> {
> String converterClassName = (String) it.next();
> ((ApplicationImpl)
> application).addConverterConfiguration(converterClassName,
>
> _dispenser.getConverterConfiguration(converterClassName));
> }
> }
> We should avoid that, and instead use RuntimeConfig object, because that is
> the right place to do that.
> The problem with this hack is what happen when Application object is wrapped.
> It is very rare that someone overrides this class, but on JSF 2.0 this
> problem become important, because it is valid to wrap Application object.
> The solution is just move the related code to RuntimeConfig object and call
> from ApplicationImpl doing a lookup to that location.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
