[jira] [Updated] (WW-4667) ParametersInterceptor excludeParams only applies to first instance of params interceptor in paramsPrepareParamsStack
[
https://issues.apache.org/jira/browse/WW-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-4667:
--
Fix Version/s: 2.3.31
> ParametersInterceptor excludeParams only applies to first instance of params
> interceptor in paramsPrepareParamsStack
>
>
> Key: WW-4667
> URL: https://issues.apache.org/jira/browse/WW-4667
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
>Affects Versions: 2.5.1
>Reporter: Chris Cranford
> Fix For: 2.3.31, 2.5.3
>
>
> I typically extend the existing stacks with my own interceptor references on
> an as needed basis, as shown below.
> The problem I face is that when I use the {{paramsPrepareParamsStack}}, I am
> noticing that the ParametersInterceptor excludes the custom defined entries
> on the first instance of the named {{params}} interceptor; however the second
> instance in the stack ignores these settings.
> {code}
>
>
>
> 2048
>
>
> dojo\..*,^struts\..*,^session\..*,^request\..*,^application\..*,^servlet(Request|Response)\..*,parameters\...*,submit,myObject\..*
>
>
>
> {code}
> I suspect the code is likely just applying the parameters to the first named
> instance and breaking the loop rather than making sure _all_ instances of the
> named interceptor have the parameters applied correctly during Struts2
> bootstrapping.
> The only workaround I've found is to avoid using the provided interceptor
> stack directly and copy it into my custom stack and explicitly set the
> excludeParams explicitly on both _params_ interceptor instances.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4667) ParametersInterceptor excludeParams only applies to first instance of params interceptor in paramsPrepareParamsStack
[
https://issues.apache.org/jira/browse/WW-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15466659#comment-15466659
]
ASF subversion and git services commented on WW-4667:
-
Commit 6f5ddca47153886611c7fbeac1bf60fb35f0b8ba in struts's branch
refs/heads/support-2-3 from [~lukaszlenart]
[ https://git-wip-us.apache.org/repos/asf?p=struts.git;h=6f5ddca ]
WW-4667 Applies params to all instances of interceptor defined in stack
> ParametersInterceptor excludeParams only applies to first instance of params
> interceptor in paramsPrepareParamsStack
>
>
> Key: WW-4667
> URL: https://issues.apache.org/jira/browse/WW-4667
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
>Affects Versions: 2.5.1
>Reporter: Chris Cranford
> Fix For: 2.5.3
>
>
> I typically extend the existing stacks with my own interceptor references on
> an as needed basis, as shown below.
> The problem I face is that when I use the {{paramsPrepareParamsStack}}, I am
> noticing that the ParametersInterceptor excludes the custom defined entries
> on the first instance of the named {{params}} interceptor; however the second
> instance in the stack ignores these settings.
> {code}
>
>
>
> 2048
>
>
> dojo\..*,^struts\..*,^session\..*,^request\..*,^application\..*,^servlet(Request|Response)\..*,parameters\...*,submit,myObject\..*
>
>
>
> {code}
> I suspect the code is likely just applying the parameters to the first named
> instance and breaking the loop rather than making sure _all_ instances of the
> named interceptor have the parameters applied correctly during Struts2
> bootstrapping.
> The only workaround I've found is to avoid using the provided interceptor
> stack directly and copy it into my custom stack and explicitly set the
> excludeParams explicitly on both _params_ interceptor instances.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4667) ParametersInterceptor excludeParams only applies to first instance of params interceptor in paramsPrepareParamsStack
[
https://issues.apache.org/jira/browse/WW-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15466679#comment-15466679
]
ASF subversion and git services commented on WW-4667:
-
Commit ab0cb82d31cbad47664dee423ddbf0894b004d27 in struts's branch
refs/heads/master from [~lukaszlenart]
[ https://git-wip-us.apache.org/repos/asf?p=struts.git;h=ab0cb82 ]
WW-4667 Applies params to all instances of interceptor defined in stack
# Conflicts:
#
xwork-core/src/main/java/com/opensymphony/xwork2/config/providers/InterceptorBuilder.java
> ParametersInterceptor excludeParams only applies to first instance of params
> interceptor in paramsPrepareParamsStack
>
>
> Key: WW-4667
> URL: https://issues.apache.org/jira/browse/WW-4667
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
>Affects Versions: 2.5.1
>Reporter: Chris Cranford
> Fix For: 2.3.31, 2.5.3
>
>
> I typically extend the existing stacks with my own interceptor references on
> an as needed basis, as shown below.
> The problem I face is that when I use the {{paramsPrepareParamsStack}}, I am
> noticing that the ParametersInterceptor excludes the custom defined entries
> on the first instance of the named {{params}} interceptor; however the second
> instance in the stack ignores these settings.
> {code}
>
>
>
> 2048
>
>
> dojo\..*,^struts\..*,^session\..*,^request\..*,^application\..*,^servlet(Request|Response)\..*,parameters\...*,submit,myObject\..*
>
>
>
> {code}
> I suspect the code is likely just applying the parameters to the first named
> instance and breaking the loop rather than making sure _all_ instances of the
> named interceptor have the parameters applied correctly during Struts2
> bootstrapping.
> The only workaround I've found is to avoid using the provided interceptor
> stack directly and copy it into my custom stack and explicitly set the
> excludeParams explicitly on both _params_ interceptor instances.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4667) ParametersInterceptor excludeParams only applies to first instance of params interceptor in paramsPrepareParamsStack
[
https://issues.apache.org/jira/browse/WW-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15466680#comment-15466680
]
ASF subversion and git services commented on WW-4667:
-
Commit f6876ce6ce38f037a7480c6ae9bc26991feeaefe in struts's branch
refs/heads/master from [~lukaszlenart]
[ https://git-wip-us.apache.org/repos/asf?p=struts.git;h=f6876ce ]
WW-4667 Applies params to all instances of interceptor defined in stack
> ParametersInterceptor excludeParams only applies to first instance of params
> interceptor in paramsPrepareParamsStack
>
>
> Key: WW-4667
> URL: https://issues.apache.org/jira/browse/WW-4667
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
>Affects Versions: 2.5.1
>Reporter: Chris Cranford
> Fix For: 2.3.31, 2.5.3
>
>
> I typically extend the existing stacks with my own interceptor references on
> an as needed basis, as shown below.
> The problem I face is that when I use the {{paramsPrepareParamsStack}}, I am
> noticing that the ParametersInterceptor excludes the custom defined entries
> on the first instance of the named {{params}} interceptor; however the second
> instance in the stack ignores these settings.
> {code}
>
>
>
> 2048
>
>
> dojo\..*,^struts\..*,^session\..*,^request\..*,^application\..*,^servlet(Request|Response)\..*,parameters\...*,submit,myObject\..*
>
>
>
> {code}
> I suspect the code is likely just applying the parameters to the first named
> instance and breaking the loop rather than making sure _all_ instances of the
> named interceptor have the parameters applied correctly during Struts2
> bootstrapping.
> The only workaround I've found is to avoid using the provided interceptor
> stack directly and copy it into my custom stack and explicitly set the
> excludeParams explicitly on both _params_ interceptor instances.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WW-4674) StrutsPrepareAndExecuteFilter should check for response commited status
[
https://issues.apache.org/jira/browse/WW-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-4674:
--
Description:
In StrutsPrepareAndExecuteFilter in doFilter method there is a code fragment
{code}
ActionMapping mapping = this.prepare.findActionMapping(request, response, true);
if(mapping == null) {
boolean handled = this.execute.executeStaticResourceRequest(request,
response);
if(!handled) {
chain.doFilter(request, response);
}
} else {
this.execute.executeAction(request, response, mapping);
}
{code}
Problem is that {{this.prepare.findActionMapping(request, response, true)}} can
commit response (in case of exception), but filter continues with execution of
chain, in my case causing problems up in the chain.
was:
In StrutsPrepareAndExecuteFilter in doFilter method there is a code fragment
{code}
ActionMapping mapping = this.prepare.findActionMapping(request, response, true);
if(mapping == null) {
boolean handled = this.execute.executeStaticResourceRequest(request,
response);
if(!handled) {
chain.doFilter(request, response);
}
} else {
this.execute.executeAction(request, response, mapping);
}
{code}
Problem is that this.prepare.findActionMapping(request, response, true) can
commit response (in case of exception), but filter continues with execution of
chain, in my case causing problems up in the chain.
> StrutsPrepareAndExecuteFilter should check for response commited status
>
>
> Key: WW-4674
> URL: https://issues.apache.org/jira/browse/WW-4674
> Project: Struts 2
> Issue Type: Improvement
>Affects Versions: 2.3.30
>Reporter: Mirek Hankus
> Fix For: 2.3.31, 2.5.3
>
>
> In StrutsPrepareAndExecuteFilter in doFilter method there is a code fragment
> {code}
> ActionMapping mapping = this.prepare.findActionMapping(request, response,
> true);
> if(mapping == null) {
> boolean handled = this.execute.executeStaticResourceRequest(request,
> response);
> if(!handled) {
>chain.doFilter(request, response);
> }
> } else {
> this.execute.executeAction(request, response, mapping);
> }
> {code}
> Problem is that {{this.prepare.findActionMapping(request, response, true)}}
> can commit response (in case of exception), but filter continues with
> execution of chain, in my case causing problems up in the chain.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4422) Component inside Component - "Could not render JSP template"
[
https://issues.apache.org/jira/browse/WW-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15466550#comment-15466550
]
Lukasz Lenart commented on WW-4422:
---
Can you post content of the both JSP files?
> Component inside Component - "Could not render JSP template"
>
>
> Key: WW-4422
> URL: https://issues.apache.org/jira/browse/WW-4422
> Project: Struts 2
> Issue Type: Bug
> Components: Other
>Affects Versions: 2.3.16.3
> Environment: Windows, Pluto Portlets
>Reporter: Mark Goertzen
> Labels: component
> Fix For: 2.3.31, 2.5.3
>
>
> Trying to render a Component inside a Component will fail with logged error
> "JspTemplateEngine.error(34) | Could not render JSP template". There is a
> workaround, which is simply to have ANY struts tag after the inner component
> declared in the of the outer component. Also, the inner component
> only causes this failure when it has struts tags inside it.
> eg. This fails:
> {code:xml}
>
>
>
>
>
>
>
> {code}
> Note that param body is rendered inside someTemplate.jsp like this:
> {code:xml}
>
> {code}
> eg. This will work exactly as expected:
> {code:xml}
>
>
>
>
>
>
>
>
> {code}
> Note that the "if" tag can be any struts tag and it will work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4667) ParametersInterceptor excludeParams only applies to first instance of params interceptor in paramsPrepareParamsStack
[
https://issues.apache.org/jira/browse/WW-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467071#comment-15467071
]
Hudson commented on WW-4667:
SUCCESS: Integrated in Jenkins build Struts-JDK7-master #517 (See
[https://builds.apache.org/job/Struts-JDK7-master/517/])
WW-4667 Applies params to all instances of interceptor defined in stack
(lukaszlenart: rev ab0cb82d31cbad47664dee423ddbf0894b004d27)
* (edit)
core/src/test/java/com/opensymphony/xwork2/config/providers/InterceptorBuilderTest.java
WW-4667 Applies params to all instances of interceptor defined in stack
(lukaszlenart: rev f6876ce6ce38f037a7480c6ae9bc26991feeaefe)
* (edit)
core/src/main/java/com/opensymphony/xwork2/config/providers/InterceptorBuilder.java
> ParametersInterceptor excludeParams only applies to first instance of params
> interceptor in paramsPrepareParamsStack
>
>
> Key: WW-4667
> URL: https://issues.apache.org/jira/browse/WW-4667
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
>Affects Versions: 2.5.1
>Reporter: Chris Cranford
> Fix For: 2.3.31, 2.5.3
>
>
> I typically extend the existing stacks with my own interceptor references on
> an as needed basis, as shown below.
> The problem I face is that when I use the {{paramsPrepareParamsStack}}, I am
> noticing that the ParametersInterceptor excludes the custom defined entries
> on the first instance of the named {{params}} interceptor; however the second
> instance in the stack ignores these settings.
> {code}
>
>
>
> 2048
>
>
> dojo\..*,^struts\..*,^session\..*,^request\..*,^application\..*,^servlet(Request|Response)\..*,parameters\...*,submit,myObject\..*
>
>
>
> {code}
> I suspect the code is likely just applying the parameters to the first named
> instance and breaking the loop rather than making sure _all_ instances of the
> named interceptor have the parameters applied correctly during Struts2
> bootstrapping.
> The only workaround I've found is to avoid using the provided interceptor
> stack directly and copy it into my custom stack and explicitly set the
> excludeParams explicitly on both _params_ interceptor instances.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WW-4685) Allow directly accessing I18N keys from Tiles defintions
[
https://issues.apache.org/jira/browse/WW-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-4685:
--
Description:
It'd be better to allow directly fetching I18N keys from Struts properties
instead of using multiple {{tiles.xml}} definitions. The latest version of
Tiles supports expression languages so it can be possible to add support for
Struts' internals.
{code:xml}
{code}
and {{home.title}} should be first evaluated as a key in resource bundle and
then as a value from ValueStack.
was:
It'd be better to allow directly fetching I18N keys from Struts properties
instead of using multiple {{tiles.xml}} definitions. The latest version of
Tiles supports expression languages so it can be possible to add support for
Struts' internals.
{code:xml}
{code}
and {{home.title}} should be first evaluated as a key in resource bundle
and then as a value from ValueStack.
> Allow directly accessing I18N keys from Tiles defintions
>
>
> Key: WW-4685
> URL: https://issues.apache.org/jira/browse/WW-4685
> Project: Struts 2
> Issue Type: Improvement
> Components: Plugin - Tiles
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Minor
> Fix For: 2.5.3
>
>
> It'd be better to allow directly fetching I18N keys from Struts properties
> instead of using multiple {{tiles.xml}} definitions. The latest version of
> Tiles supports expression languages so it can be possible to add support for
> Struts' internals.
> {code:xml}
>
>
>
>
> {code}
> and {{home.title}} should be first evaluated as a key in resource bundle and
> then as a value from ValueStack.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (WW-4685) Allow directly accessing I18N keys from Tiles defintions
[
https://issues.apache.org/jira/browse/WW-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart resolved WW-4685.
---
Resolution: Fixed
Done
> Allow directly accessing I18N keys from Tiles defintions
>
>
> Key: WW-4685
> URL: https://issues.apache.org/jira/browse/WW-4685
> Project: Struts 2
> Issue Type: Improvement
> Components: Plugin - Tiles
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Minor
> Fix For: 2.5.3
>
>
> It'd be better to allow directly fetching I18N keys from Struts properties
> instead of using multiple {{tiles.xml}} definitions. The latest version of
> Tiles supports expression languages so it can be possible to add support for
> Struts' internals.
> {code:xml}
>
>
>
>
> {code}
> and {{home.title}} should be first evaluated as a key in resource bundle and
> then as a value from ValueStack.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4685) Allow directly accessing I18N keys from Tiles defintions
[
https://issues.apache.org/jira/browse/WW-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15468317#comment-15468317
]
ASF subversion and git services commented on WW-4685:
-
Commit 1bed00d3d7269bbe11cd3ec1711400e050ef57b4 in struts's branch
refs/heads/master from [~lukaszlenart]
[ https://git-wip-us.apache.org/repos/asf?p=struts.git;h=1bed00d ]
WW-4685 Supports evaluating expressions from tiles definitions as a Struts
values
> Allow directly accessing I18N keys from Tiles defintions
>
>
> Key: WW-4685
> URL: https://issues.apache.org/jira/browse/WW-4685
> Project: Struts 2
> Issue Type: Improvement
> Components: Plugin - Tiles
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Minor
> Fix For: 2.5.3
>
>
> It'd be better to allow directly fetching I18N keys from Struts properties
> instead of using multiple {{tiles.xml}} definitions. The latest version of
> Tiles supports expression languages so it can be possible to add support for
> Struts' internals.
> {code:xml}
>
>
>
>
> {code}
> and {{home.title}} should be first evaluated as a key in resource bundle and
> then as a value from ValueStack.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4685) Allow directly accessing I18N keys from Tiles defintions
[
https://issues.apache.org/jira/browse/WW-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15468781#comment-15468781
]
Hudson commented on WW-4685:
SUCCESS: Integrated in Jenkins build Struts-JDK7-master #518 (See
[https://builds.apache.org/job/Struts-JDK7-master/518/])
WW-4685 Supports evaluating expressions from tiles definitions as a
(lukaszlenart: rev 1bed00d3d7269bbe11cd3ec1711400e050ef57b4)
* (add)
plugins/tiles/src/main/java/org/apache/struts2/tiles/StrutsAttributeEvaluator.java
* (edit)
plugins/tiles/src/main/java/org/apache/struts2/tiles/StrutsTilesContainerFactory.java
> Allow directly accessing I18N keys from Tiles defintions
>
>
> Key: WW-4685
> URL: https://issues.apache.org/jira/browse/WW-4685
> Project: Struts 2
> Issue Type: Improvement
> Components: Plugin - Tiles
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Minor
> Fix For: 2.5.3
>
>
> It'd be better to allow directly fetching I18N keys from Struts properties
> instead of using multiple {{tiles.xml}} definitions. The latest version of
> Tiles supports expression languages so it can be possible to add support for
> Struts' internals.
> {code:xml}
>
>
>
>
> {code}
> and {{home.title}} should be first evaluated as a key in resource bundle and
> then as a value from ValueStack.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
