You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-issues@incubator.apache.org by "Scott O'Bryan (JIRA)" <ad...@incubator.apache.org> on 2007/02/13 00:30:05 UTC
[jira] Created: (ADFFACES-379) Configurator.endRequest fails to
execute under certain conditions
Configurator.endRequest fails to execute under certain conditions
-----------------------------------------------------------------
Key: ADFFACES-379
URL: https://issues.apache.org/jira/browse/ADFFACES-379
Project: MyFaces ADF-Faces
Issue Type: Bug
Components: Portlet
Environment: JSR-168
Reporter: Scott O'Bryan
When the filter is not run (like in a Portlet) there are certain scenarios where the Configurator.endRequest is not being called. Looking at the implementation, there is also RequestContext initialization in Trinidad Filters and a lot of old stuff which is just muddying the waters and making the cleanup code more complex.
We need to remove the obsolete code for RequestContext initialization in the TrinidadPhaseListener (as this is now handled by the Configurators regardless of whether the filter is run or not, and clean up handling of Configurator execution outside of the filter usecase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ADFFACES-379) Configurator.endRequest fails to
execute under certain conditions
Posted by "Scott O'Bryan (JIRA)" <ad...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/ADFFACES-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott O'Bryan updated ADFFACES-379:
-----------------------------------
Attachment: 13-ADFFACES-379.patch
This old patch contained an unintended file (web.xml). web.xml has been removed from this version of the patch. It is important to note that other then some formatting, the previous patch will have no impact on the previous patch.
> Configurator.endRequest fails to execute under certain conditions
> -----------------------------------------------------------------
>
> Key: ADFFACES-379
> URL: https://issues.apache.org/jira/browse/ADFFACES-379
> Project: MyFaces ADF-Faces
> Issue Type: Bug
> Components: Portlet
> Environment: JSR-168
> Reporter: Scott O'Bryan
> Attachments: 13-ADFFACES-379.patch, 13-ADFFACES-379.patch
>
>
> When the filter is not run (like in a Portlet) there are certain scenarios where the Configurator.endRequest is not being called. Looking at the implementation, there is also RequestContext initialization in Trinidad Filters and a lot of old stuff which is just muddying the waters and making the cleanup code more complex.
> We need to remove the obsolete code for RequestContext initialization in the TrinidadPhaseListener (as this is now handled by the Configurators regardless of whether the filter is run or not, and clean up handling of Configurator execution outside of the filter usecase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (ADFFACES-379) Configurator.endRequest fails
to execute under certain conditions
Posted by Scott O'Bryan <da...@gmail.com>.
Hey Adam,
Good catch. Thank you. If you need help merging this into the latest
1.2 branch let me know. The patch does not apply cleanly, but merging
everything is not terribly difficult.
Scott
Adam Winer (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/ADFFACES-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Adam Winer updated ADFFACES-379:
> --------------------------------
>
> Resolution: Fixed
> Status: Resolved (was: Patch Available)
>
> Checked in. While testing this patch, I noticed some problems with the file upload code, especially
> in handling of non-ISO-8859-1 characters. I'm 99% sure these were there before this patch,
> and just unnoticed, but fixed them while the code was in front of me.
>
>
>> Configurator.endRequest fails to execute under certain conditions
>> -----------------------------------------------------------------
>>
>> Key: ADFFACES-379
>> URL: https://issues.apache.org/jira/browse/ADFFACES-379
>> Project: MyFaces ADF-Faces
>> Issue Type: Bug
>> Components: Portlet
>> Environment: JSR-168
>> Reporter: Scott O'Bryan
>> Attachments: 13-ADFFACES-379.patch, 13-ADFFACES-379.patch
>>
>>
>> When the filter is not run (like in a Portlet) there are certain scenarios where the Configurator.endRequest is not being called. Looking at the implementation, there is also RequestContext initialization in Trinidad Filters and a lot of old stuff which is just muddying the waters and making the cleanup code more complex.
>> We need to remove the obsolete code for RequestContext initialization in the TrinidadPhaseListener (as this is now handled by the Configurators regardless of whether the filter is run or not, and clean up handling of Configurator execution outside of the filter usecase.
>>
>
>
[jira] Updated: (ADFFACES-379) Configurator.endRequest fails to
execute under certain conditions
Posted by "Adam Winer (JIRA)" <ad...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/ADFFACES-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Winer updated ADFFACES-379:
--------------------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
Checked in. While testing this patch, I noticed some problems with the file upload code, especially
in handling of non-ISO-8859-1 characters. I'm 99% sure these were there before this patch,
and just unnoticed, but fixed them while the code was in front of me.
> Configurator.endRequest fails to execute under certain conditions
> -----------------------------------------------------------------
>
> Key: ADFFACES-379
> URL: https://issues.apache.org/jira/browse/ADFFACES-379
> Project: MyFaces ADF-Faces
> Issue Type: Bug
> Components: Portlet
> Environment: JSR-168
> Reporter: Scott O'Bryan
> Attachments: 13-ADFFACES-379.patch, 13-ADFFACES-379.patch
>
>
> When the filter is not run (like in a Portlet) there are certain scenarios where the Configurator.endRequest is not being called. Looking at the implementation, there is also RequestContext initialization in Trinidad Filters and a lot of old stuff which is just muddying the waters and making the cleanup code more complex.
> We need to remove the obsolete code for RequestContext initialization in the TrinidadPhaseListener (as this is now handled by the Configurators regardless of whether the filter is run or not, and clean up handling of Configurator execution outside of the filter usecase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ADFFACES-379) Configurator.endRequest fails to
execute under certain conditions
Posted by "Matthias Weßendorf (JIRA)" <ad...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/ADFFACES-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthias Weßendorf updated ADFFACES-379:
----------------------------------------
Fix Version/s: 1.0.0-incubating-core
Affects Version/s: 1.0.0-incubating-core
> Configurator.endRequest fails to execute under certain conditions
> -----------------------------------------------------------------
>
> Key: ADFFACES-379
> URL: https://issues.apache.org/jira/browse/ADFFACES-379
> Project: MyFaces ADF-Faces
> Issue Type: Bug
> Components: Portlet
> Affects Versions: 1.0.0-incubating-core
> Environment: JSR-168
> Reporter: Scott O'Bryan
> Fix For: 1.0.0-incubating-core
>
> Attachments: 13-ADFFACES-379.patch, 13-ADFFACES-379.patch
>
>
> When the filter is not run (like in a Portlet) there are certain scenarios where the Configurator.endRequest is not being called. Looking at the implementation, there is also RequestContext initialization in Trinidad Filters and a lot of old stuff which is just muddying the waters and making the cleanup code more complex.
> We need to remove the obsolete code for RequestContext initialization in the TrinidadPhaseListener (as this is now handled by the Configurators regardless of whether the filter is run or not, and clean up handling of Configurator execution outside of the filter usecase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ADFFACES-379) Configurator.endRequest fails to
execute under certain conditions
Posted by "Jeanne Waldman (JIRA)" <ad...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/ADFFACES-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473262 ]
Jeanne Waldman commented on ADFFACES-379:
-----------------------------------------
It looks like Adam applied it to the JSF1.2 branch only. I applied this to trunk as well as requested by Scott.
> Configurator.endRequest fails to execute under certain conditions
> -----------------------------------------------------------------
>
> Key: ADFFACES-379
> URL: https://issues.apache.org/jira/browse/ADFFACES-379
> Project: MyFaces ADF-Faces
> Issue Type: Bug
> Components: Portlet
> Environment: JSR-168
> Reporter: Scott O'Bryan
> Attachments: 13-ADFFACES-379.patch, 13-ADFFACES-379.patch
>
>
> When the filter is not run (like in a Portlet) there are certain scenarios where the Configurator.endRequest is not being called. Looking at the implementation, there is also RequestContext initialization in Trinidad Filters and a lot of old stuff which is just muddying the waters and making the cleanup code more complex.
> We need to remove the obsolete code for RequestContext initialization in the TrinidadPhaseListener (as this is now handled by the Configurators regardless of whether the filter is run or not, and clean up handling of Configurator execution outside of the filter usecase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ADFFACES-379) Configurator.endRequest fails to
execute under certain conditions
Posted by "Scott O'Bryan (JIRA)" <ad...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/ADFFACES-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott O'Bryan updated ADFFACES-379:
-----------------------------------
Status: Patch Available (was: Open)
> Configurator.endRequest fails to execute under certain conditions
> -----------------------------------------------------------------
>
> Key: ADFFACES-379
> URL: https://issues.apache.org/jira/browse/ADFFACES-379
> Project: MyFaces ADF-Faces
> Issue Type: Bug
> Components: Portlet
> Environment: JSR-168
> Reporter: Scott O'Bryan
> Attachments: 13-ADFFACES-379.patch
>
>
> When the filter is not run (like in a Portlet) there are certain scenarios where the Configurator.endRequest is not being called. Looking at the implementation, there is also RequestContext initialization in Trinidad Filters and a lot of old stuff which is just muddying the waters and making the cleanup code more complex.
> We need to remove the obsolete code for RequestContext initialization in the TrinidadPhaseListener (as this is now handled by the Configurators regardless of whether the filter is run or not, and clean up handling of Configurator execution outside of the filter usecase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ADFFACES-379) Configurator.endRequest fails to
execute under certain conditions
Posted by "Scott O'Bryan (JIRA)" <ad...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/ADFFACES-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott O'Bryan updated ADFFACES-379:
-----------------------------------
Attachment: 13-ADFFACES-379.patch
This patch cleans up a bunch of code, resolves the issues with endRequest not being run under some circumstances, and removes a hack in resourceServlet to set ResponseComplete in order to handle cleanup.
All in all, a much cleaner implementation of the Configurator's cleanup code.
> Configurator.endRequest fails to execute under certain conditions
> -----------------------------------------------------------------
>
> Key: ADFFACES-379
> URL: https://issues.apache.org/jira/browse/ADFFACES-379
> Project: MyFaces ADF-Faces
> Issue Type: Bug
> Components: Portlet
> Environment: JSR-168
> Reporter: Scott O'Bryan
> Attachments: 13-ADFFACES-379.patch
>
>
> When the filter is not run (like in a Portlet) there are certain scenarios where the Configurator.endRequest is not being called. Looking at the implementation, there is also RequestContext initialization in Trinidad Filters and a lot of old stuff which is just muddying the waters and making the cleanup code more complex.
> We need to remove the obsolete code for RequestContext initialization in the TrinidadPhaseListener (as this is now handled by the Configurators regardless of whether the filter is run or not, and clean up handling of Configurator execution outside of the filter usecase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.