You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Andy Schwartz (JIRA)" <de...@myfaces.apache.org> on 2011/01/10 22:57:45 UTC
[jira] Created: (TRINIDAD-2002) TrinidadFilterImpl FacesContext
initialization
TrinidadFilterImpl FacesContext initialization
----------------------------------------------
Key: TRINIDAD-2002
URL: https://issues.apache.org/jira/browse/TRINIDAD-2002
Project: MyFaces Trinidad
Issue Type: Improvement
Affects Versions: 2.0.0-alpha
Reporter: Andy Schwartz
Priority: Minor
ADF Faces hooks into Trinidad's TrinidadFilterImpl sub-filter service and uses this to perform early configuration/initialization work. In particular, we use the ApplicationFactory to get at the Application instance and then create/add converters to the Application.
This works fine on Mojarra 2.0.x releases.
However, this fails in both:
- MyFaces 2.0.x
- Mojarra 2.1.x
In both cases, the reason for the failure is that access to the FacesContext is required but is not yet available. In MyFaces 2.0.x, the FacesContext/ExternalContext is required by Application.createConverter()/setConverterProperties() in order to determine the value of the "javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE" context parameter. In Mojarra 2.1.x, the ApplicationFactory requires access to the FacesContext in order to create the Application instance.
While we can work around this issue at the ADF Faces level, TrinidadFilterImpl is already well positioned to address this - ie. TrinidadFilterImpl has access to the PseudoFacesContext and already sets this up for other cases (eg. for Configurator.beginRequest()).
I am logging this issue to request that we take advantage of the existing support that TrinidadFilterImpl/PseudoFacesContext provides for early FacesContext access and extend this to TrinidadFilterImpl.init().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-2002) TrinidadFilterImpl FacesContext
initialization
Posted by "Andy Schwartz (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Schwartz updated TRINIDAD-2002:
------------------------------------
Status: Patch Available (was: Open)
> TrinidadFilterImpl FacesContext initialization
> ----------------------------------------------
>
> Key: TRINIDAD-2002
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2002
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 2.0.0-alpha
> Reporter: Andy Schwartz
> Priority: Minor
> Attachments: TRINIDAD-2002.patch
>
>
> ADF Faces hooks into Trinidad's TrinidadFilterImpl sub-filter service and uses this to perform early configuration/initialization work. In particular, we use the ApplicationFactory to get at the Application instance and then create/add converters to the Application.
> This works fine on Mojarra 2.0.x releases.
> However, this fails in both:
> - MyFaces 2.0.x
> - Mojarra 2.1.x
> In both cases, the reason for the failure is that access to the FacesContext is required but is not yet available. In MyFaces 2.0.x, the FacesContext/ExternalContext is required by Application.createConverter()/setConverterProperties() in order to determine the value of the "javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE" context parameter. In Mojarra 2.1.x, the ApplicationFactory requires access to the FacesContext in order to create the Application instance.
> While we can work around this issue at the ADF Faces level, TrinidadFilterImpl is already well positioned to address this - ie. TrinidadFilterImpl has access to the PseudoFacesContext and already sets this up for other cases (eg. for Configurator.beginRequest()).
> I am logging this issue to request that we take advantage of the existing support that TrinidadFilterImpl/PseudoFacesContext provides for early FacesContext access and extend this to TrinidadFilterImpl.init().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-2002) TrinidadFilterImpl FacesContext
initialization
Posted by "Max Starets (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Max Starets updated TRINIDAD-2002:
----------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0.3-core
Status: Resolved (was: Patch Available)
patch committed.
> TrinidadFilterImpl FacesContext initialization
> ----------------------------------------------
>
> Key: TRINIDAD-2002
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2002
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 2.0.0-alpha
> Reporter: Andy Schwartz
> Priority: Minor
> Fix For: 2.0.0.3-core
>
> Attachments: TRINIDAD-2002.patch
>
>
> ADF Faces hooks into Trinidad's TrinidadFilterImpl sub-filter service and uses this to perform early configuration/initialization work. In particular, we use the ApplicationFactory to get at the Application instance and then create/add converters to the Application.
> This works fine on Mojarra 2.0.x releases.
> However, this fails in both:
> - MyFaces 2.0.x
> - Mojarra 2.1.x
> In both cases, the reason for the failure is that access to the FacesContext is required but is not yet available. In MyFaces 2.0.x, the FacesContext/ExternalContext is required by Application.createConverter()/setConverterProperties() in order to determine the value of the "javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE" context parameter. In Mojarra 2.1.x, the ApplicationFactory requires access to the FacesContext in order to create the Application instance.
> While we can work around this issue at the ADF Faces level, TrinidadFilterImpl is already well positioned to address this - ie. TrinidadFilterImpl has access to the PseudoFacesContext and already sets this up for other cases (eg. for Configurator.beginRequest()).
> I am logging this issue to request that we take advantage of the existing support that TrinidadFilterImpl/PseudoFacesContext provides for early FacesContext access and extend this to TrinidadFilterImpl.init().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-2002) TrinidadFilterImpl FacesContext
initialization
Posted by "Andy Schwartz (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979792#action_12979792 ]
Andy Schwartz commented on TRINIDAD-2002:
-----------------------------------------
This patch:
https://issues.apache.org/jira/secure/attachment/12467925/TRINIDAD-2002.patch
Demonstrates how we might implement this change.
> TrinidadFilterImpl FacesContext initialization
> ----------------------------------------------
>
> Key: TRINIDAD-2002
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2002
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 2.0.0-alpha
> Reporter: Andy Schwartz
> Priority: Minor
> Attachments: TRINIDAD-2002.patch
>
>
> ADF Faces hooks into Trinidad's TrinidadFilterImpl sub-filter service and uses this to perform early configuration/initialization work. In particular, we use the ApplicationFactory to get at the Application instance and then create/add converters to the Application.
> This works fine on Mojarra 2.0.x releases.
> However, this fails in both:
> - MyFaces 2.0.x
> - Mojarra 2.1.x
> In both cases, the reason for the failure is that access to the FacesContext is required but is not yet available. In MyFaces 2.0.x, the FacesContext/ExternalContext is required by Application.createConverter()/setConverterProperties() in order to determine the value of the "javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE" context parameter. In Mojarra 2.1.x, the ApplicationFactory requires access to the FacesContext in order to create the Application instance.
> While we can work around this issue at the ADF Faces level, TrinidadFilterImpl is already well positioned to address this - ie. TrinidadFilterImpl has access to the PseudoFacesContext and already sets this up for other cases (eg. for Configurator.beginRequest()).
> I am logging this issue to request that we take advantage of the existing support that TrinidadFilterImpl/PseudoFacesContext provides for early FacesContext access and extend this to TrinidadFilterImpl.init().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.