You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org> on 2010/09/24 01:42:32 UTC
[jira] Created: (MYFACES-2928) FacesConfigurator cast for
ApplicationImpl directly to load converter configuration, instead use
RuntimeConfig object
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
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.
[jira] Resolved: (MYFACES-2928) FacesConfigurator cast for
ApplicationImpl directly to load converter configuration, instead use
RuntimeConfig object
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ 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.