[ 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.