You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Herbert Poul (JIRA)" <ji...@apache.org> on 2008/07/15 15:34:10 UTC
[jira] Created: (WW-2720) dispatching after action phase renders
with different stack/TextProvider
dispatching after action phase renders with different stack/TextProvider
------------------------------------------------------------------------
Key: WW-2720
URL: https://issues.apache.org/struts/browse/WW-2720
Project: Struts 2
Issue Type: Bug
Components: Plugin - Portlet
Reporter: Herbert Poul
Priority: Minor
Attachments: portletstateinterceptor.patch
when dispatching after an action phase to a servlet the stack is restored in the render phase by appending it to the stack of the action phase..
but when using the <s:text ..> jsp tag the first TextProvider of the stack is used (by TextProviderHelper#getText) - no matter if it returns a match or not .. this is why my translations aren't working after the action phase.. (i use a action extending ActionSupport with message bundles in the same package)
the problem was fixed for me when i tried to restore the stack in the 'PortletStackInterceptor' by putting the stack from the action phase in front of the current stack, instead of appending it at the end... (very simple patch .. i simply added a '0,' ;) )
is that a useful solution ?
thanks,
herbert
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-2720) dispatching after action phase renders
with different stack/TextProvider
Posted by "Herbert Poul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Herbert Poul updated WW-2720:
-----------------------------
Attachment: portletstateinterceptor.patch
fixed the problem for me .. very very small modification
> dispatching after action phase renders with different stack/TextProvider
> ------------------------------------------------------------------------
>
> Key: WW-2720
> URL: https://issues.apache.org/struts/browse/WW-2720
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - Portlet
> Reporter: Herbert Poul
> Priority: Minor
> Attachments: portletstateinterceptor.patch
>
>
> when dispatching after an action phase to a servlet the stack is restored in the render phase by appending it to the stack of the action phase..
> but when using the <s:text ..> jsp tag the first TextProvider of the stack is used (by TextProviderHelper#getText) - no matter if it returns a match or not .. this is why my translations aren't working after the action phase.. (i use a action extending ActionSupport with message bundles in the same package)
> the problem was fixed for me when i tried to restore the stack in the 'PortletStackInterceptor' by putting the stack from the action phase in front of the current stack, instead of appending it at the end... (very simple patch .. i simply added a '0,' ;) )
> is that a useful solution ?
> thanks,
> herbert
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-2720) dispatching after action phase renders
with different stack/TextProvider
Posted by "Nils-Helge Garli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45355#action_45355 ]
Nils-Helge Garli commented on WW-2720:
--------------------------------------
It didn't break any tests, so I'm applying the patch. Thanks.
> dispatching after action phase renders with different stack/TextProvider
> ------------------------------------------------------------------------
>
> Key: WW-2720
> URL: https://issues.apache.org/struts/browse/WW-2720
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - Portlet
> Reporter: Herbert Poul
> Priority: Minor
> Fix For: 2.1.3
>
> Attachments: portletstateinterceptor.patch
>
>
> when dispatching after an action phase to a servlet the stack is restored in the render phase by appending it to the stack of the action phase..
> but when using the <s:text ..> jsp tag the first TextProvider of the stack is used (by TextProviderHelper#getText) - no matter if it returns a match or not .. this is why my translations aren't working after the action phase.. (i use a action extending ActionSupport with message bundles in the same package)
> the problem was fixed for me when i tried to restore the stack in the 'PortletStackInterceptor' by putting the stack from the action phase in front of the current stack, instead of appending it at the end... (very simple patch .. i simply added a '0,' ;) )
> is that a useful solution ?
> thanks,
> herbert
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WW-2720) dispatching after action phase renders
with different stack/TextProvider
Posted by "Nils-Helge Garli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nils-Helge Garli resolved WW-2720.
----------------------------------
Resolution: Fixed
Patch applied.
> dispatching after action phase renders with different stack/TextProvider
> ------------------------------------------------------------------------
>
> Key: WW-2720
> URL: https://issues.apache.org/struts/browse/WW-2720
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - Portlet
> Reporter: Herbert Poul
> Priority: Minor
> Fix For: 2.1.3
>
> Attachments: portletstateinterceptor.patch
>
>
> when dispatching after an action phase to a servlet the stack is restored in the render phase by appending it to the stack of the action phase..
> but when using the <s:text ..> jsp tag the first TextProvider of the stack is used (by TextProviderHelper#getText) - no matter if it returns a match or not .. this is why my translations aren't working after the action phase.. (i use a action extending ActionSupport with message bundles in the same package)
> the problem was fixed for me when i tried to restore the stack in the 'PortletStackInterceptor' by putting the stack from the action phase in front of the current stack, instead of appending it at the end... (very simple patch .. i simply added a '0,' ;) )
> is that a useful solution ?
> thanks,
> herbert
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-2720) dispatching after action phase renders
with different stack/TextProvider
Posted by "James Holmes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Holmes updated WW-2720:
-----------------------------
Fix Version/s: 2.1.3
> dispatching after action phase renders with different stack/TextProvider
> ------------------------------------------------------------------------
>
> Key: WW-2720
> URL: https://issues.apache.org/struts/browse/WW-2720
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - Portlet
> Reporter: Herbert Poul
> Priority: Minor
> Fix For: 2.1.3
>
> Attachments: portletstateinterceptor.patch
>
>
> when dispatching after an action phase to a servlet the stack is restored in the render phase by appending it to the stack of the action phase..
> but when using the <s:text ..> jsp tag the first TextProvider of the stack is used (by TextProviderHelper#getText) - no matter if it returns a match or not .. this is why my translations aren't working after the action phase.. (i use a action extending ActionSupport with message bundles in the same package)
> the problem was fixed for me when i tried to restore the stack in the 'PortletStackInterceptor' by putting the stack from the action phase in front of the current stack, instead of appending it at the end... (very simple patch .. i simply added a '0,' ;) )
> is that a useful solution ?
> thanks,
> herbert
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.