[jira] [Comment Edited] (WW-4558) contentType override ignored for JSONInterceptor
[ https://issues.apache.org/jira/browse/WW-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15286574#comment-15286574 ] Jasper Rosenberg edited comment on WW-4558 at 5/17/16 1:06 PM: --- Makes sense to me, thanks! was (Author: perfnorm): Makes sense to me! > contentType override ignored for JSONInterceptor > > > Key: WW-4558 > URL: https://issues.apache.org/jira/browse/WW-4558 > Project: Struts 2 > Issue Type: Bug > Components: Plugin - JSON >Affects Versions: 2.3.24 >Reporter: Jasper Rosenberg >Priority: Minor > Fix For: 2.5.x > > > JSONInterceptor takes a contentType parameter, but as far as I can tell does > nothing with it. I would think a reasonable way to use it would be to have > it used if available, rather than the content type from the request so that > the interceptor can be used when receiving a JSON post from a third party > that does not set the correct content type. > PR https://github.com/apache/struts/pull/87 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4558) contentType override ignored for JSONInterceptor
[ https://issues.apache.org/jira/browse/WW-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15286574#comment-15286574 ] Jasper Rosenberg commented on WW-4558: -- Makes sense to me! > contentType override ignored for JSONInterceptor > > > Key: WW-4558 > URL: https://issues.apache.org/jira/browse/WW-4558 > Project: Struts 2 > Issue Type: Bug > Components: Plugin - JSON >Affects Versions: 2.3.24 >Reporter: Jasper Rosenberg >Priority: Minor > Fix For: 2.5.x > > > JSONInterceptor takes a contentType parameter, but as far as I can tell does > nothing with it. I would think a reasonable way to use it would be to have > it used if available, rather than the content type from the request so that > the interceptor can be used when receiving a JSON post from a third party > that does not set the correct content type. > PR https://github.com/apache/struts/pull/87 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4558) contentType override ignored for JSONInterceptor
[ https://issues.apache.org/jira/browse/WW-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15146789#comment-15146789 ] Jasper Rosenberg commented on WW-4558: -- That makes sense to me. > contentType override ignored for JSONInterceptor > > > Key: WW-4558 > URL: https://issues.apache.org/jira/browse/WW-4558 > Project: Struts 2 > Issue Type: Bug > Components: Plugin - JSON >Affects Versions: 2.3.24 >Reporter: Jasper Rosenberg >Priority: Minor > Fix For: 2.3.25 > > > JSONInterceptor takes a contentType parameter, but as far as I can tell does > nothing with it. I would think a reasonable way to use it would be to have > it used if available, rather than the content type from the request so that > the interceptor can be used when receiving a JSON post from a third party > that does not set the correct content type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4558) contentType override ignored for JSONInterceptor
[ https://issues.apache.org/jira/browse/WW-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14985271#comment-14985271 ] Jasper Rosenberg commented on WW-4558: -- That makes sense to me, and it avoid any issue where someone was currently using contentType expecting it to do something. > contentType override ignored for JSONInterceptor > > > Key: WW-4558 > URL: https://issues.apache.org/jira/browse/WW-4558 > Project: Struts 2 > Issue Type: Bug > Components: Plugin - JSON >Affects Versions: 2.3.24 >Reporter: Jasper Rosenberg >Priority: Minor > Fix For: 2.3.x > > > JSONInterceptor takes a contentType parameter, but as far as I can tell does > nothing with it. I would think a reasonable way to use it would be to have > it used if available, rather than the content type from the request so that > the interceptor can be used when receiving a JSON post from a third party > that does not set the correct content type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4558) contentType override ignored for JSONInterceptor
[ https://issues.apache.org/jira/browse/WW-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14983998#comment-14983998 ] Jasper Rosenberg commented on WW-4558: -- This is the interceptor, so I'm suggesting using it as the content type of the request. > contentType override ignored for JSONInterceptor > > > Key: WW-4558 > URL: https://issues.apache.org/jira/browse/WW-4558 > Project: Struts 2 > Issue Type: Bug > Components: Plugin - JSON >Affects Versions: 2.3.24 >Reporter: Jasper Rosenberg >Priority: Minor > Fix For: 2.3.x > > > JSONInterceptor takes a contentType parameter, but as far as I can tell does > nothing with it. I would think a reasonable way to use it would be to have > it used if available, rather than the content type from the request so that > the interceptor can be used when receiving a JSON post from a third party > that does not set the correct content type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4558) contentType override ignored for JSONInterceptor
[ https://issues.apache.org/jira/browse/WW-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14982446#comment-14982446 ] Jasper Rosenberg commented on WW-4558: -- Definitely could be dropped as it is unused, but it could instead serve the purpose of overwriting the submitted content type to support the cases where you want to use the JSON interceptor, but the content type you are being passed is incorrect (say from a 3rd party). > contentType override ignored for JSONInterceptor > > > Key: WW-4558 > URL: https://issues.apache.org/jira/browse/WW-4558 > Project: Struts 2 > Issue Type: Bug > Components: Plugin - JSON >Affects Versions: 2.3.24 >Reporter: Jasper Rosenberg >Priority: Minor > Fix For: 2.3.x > > > JSONInterceptor takes a contentType parameter, but as far as I can tell does > nothing with it. I would think a reasonable way to use it would be to have > it used if available, rather than the content type from the request so that > the interceptor can be used when receiving a JSON post from a third party > that does not set the correct content type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WW-4558) contentType override ignored for JSONInterceptor
Jasper Rosenberg created WW-4558: Summary: contentType override ignored for JSONInterceptor Key: WW-4558 URL: https://issues.apache.org/jira/browse/WW-4558 Project: Struts 2 Issue Type: Bug Components: Plugin - JSON Affects Versions: 2.3.24 Reporter: Jasper Rosenberg Priority: Minor JSONInterceptor takes a contentType parameter, but as far as I can tell does nothing with it. I would think a reasonable way to use it would be to have it used if available, rather than the content type from the request so that the interceptor can be used when receiving a JSON post from a third party that does not set the correct content type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4556) In theme simple, move form-close.ftl tooltip code into own file
[
https://issues.apache.org/jira/browse/WW-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14974047#comment-14974047
]
Jasper Rosenberg commented on WW-4556:
--
There is no urgency as I can just override all of form-close.ftl, but obviously
it would be nice to be sooner since it would be much cleaner.
> In theme simple, move form-close.ftl tooltip code into own file
> ---
>
> Key: WW-4556
> URL: https://issues.apache.org/jira/browse/WW-4556
> Project: Struts 2
> Issue Type: Improvement
> Components: Plugin - Tags
>Affects Versions: 2.3.24
>Reporter: Jasper Rosenberg
>Priority: Minor
> Labels: simple, theme, tooltip
>
> I'd like to be able to turn off the struts tooltip js/css without having to
> override the whole form-close.ftl file. This would be particularly useful
> when using the bootstrap plugin since I'm already importing tooltip js/css as
> part of my bootstrap js/css.
> I'd just move the block
> {code}
> <#--
> Code that will add javascript needed for tooltips
> --><#t/>
> <#if (parameters.hasTooltip?default(false))><#t/>
> <#lt/>
> <#lt/>
> <#lt/>"/>
>
> <#t/>
> {code}
> to a file like form-close-tooltips.ftl
> And replace it in form-close.ftl with
> {code}
> <#include
> "/${parameters.templateDir}/${parameters.expandTheme}/form-close-tooltips.ftl"
> />
> {code}
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WW-4556) In theme simple, move form-close.ftl tooltip code into own file
Jasper Rosenberg created WW-4556:
Summary: In theme simple, move form-close.ftl tooltip code into
own file
Key: WW-4556
URL: https://issues.apache.org/jira/browse/WW-4556
Project: Struts 2
Issue Type: Improvement
Components: Plugin - Tags
Affects Versions: 2.3.24
Reporter: Jasper Rosenberg
Priority: Minor
I'd like to be able to turn off the struts tooltip js/css without having to
override the whole form-close.ftl file. This would be particularly useful when
using the bootstrap plugin since I'm already importing tooltip js/css as part
of my bootstrap js/css.
I'd just move the block
{code}
<#--
Code that will add javascript needed for tooltips
--><#t/>
<#if (parameters.hasTooltip?default(false))><#t/>
<#lt/>
<#lt/>
<#lt/>"/>
<#t/>
{code}
to a file like form-close-tooltips.ftl
And replace it in form-close.ftl with
{code}
<#include
"/${parameters.templateDir}/${parameters.expandTheme}/form-close-tooltips.ftl"
/>
{code}
Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4556) In theme simple, move form-close.ftl tooltip code into own file
[
https://issues.apache.org/jira/browse/WW-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14970856#comment-14970856
]
Jasper Rosenberg commented on WW-4556:
--
Probably should also switch parameters.hasTooltip?default(false) to the more
modern (parameters.hasTooltip)!false too while in there...
> In theme simple, move form-close.ftl tooltip code into own file
> ---
>
> Key: WW-4556
> URL: https://issues.apache.org/jira/browse/WW-4556
> Project: Struts 2
> Issue Type: Improvement
> Components: Plugin - Tags
>Affects Versions: 2.3.24
>Reporter: Jasper Rosenberg
>Priority: Minor
> Labels: simple, theme, tooltip
>
> I'd like to be able to turn off the struts tooltip js/css without having to
> override the whole form-close.ftl file. This would be particularly useful
> when using the bootstrap plugin since I'm already importing tooltip js/css as
> part of my bootstrap js/css.
> I'd just move the block
> {code}
> <#--
> Code that will add javascript needed for tooltips
> --><#t/>
> <#if (parameters.hasTooltip?default(false))><#t/>
> <#lt/>
> <#lt/>
> <#lt/>"/>
>
> <#t/>
> {code}
> to a file like form-close-tooltips.ftl
> And replace it in form-close.ftl with
> {code}
> <#include
> "/${parameters.templateDir}/${parameters.expandTheme}/form-close-tooltips.ftl"
> />
> {code}
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WW-4552) Make it easier to extend to use own ActionInvocation
Jasper Rosenberg created WW-4552: Summary: Make it easier to extend to use own ActionInvocation Key: WW-4552 URL: https://issues.apache.org/jira/browse/WW-4552 Project: Struts 2 Issue Type: Improvement Components: Core Actions Affects Versions: 2.3.24 Reporter: Jasper Rosenberg Priority: Trivial I needed to extend DefaultActionProxyFactory to return my own ActionInvocation, but I had to override all of createActionProxy() to do so. Seems like a safe change to break out the ActionInvocation creation to make it easier to just override that piece. See pull request: https://github.com/apache/struts/pull/54 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WW-4553) Make it easier to extend to override interceptor stack
Jasper Rosenberg created WW-4553: Summary: Make it easier to extend to override interceptor stack Key: WW-4553 URL: https://issues.apache.org/jira/browse/WW-4553 Project: Struts 2 Issue Type: Improvement Components: Core Actions Affects Versions: 2.3.24 Reporter: Jasper Rosenberg Priority: Trivial Just as createAction is split out from init, it would be great to split out creating the interceptor iterator creation so it can be overridden without having to override all of init(). (Needed this to always prepend an i18n interceptor to all stacks). See pull request: https://github.com/apache/struts/pull/55 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WW-4514) DefaultUrlHelper.buildParametersString appends just ? if collection is empty
[ https://issues.apache.org/jira/browse/WW-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasper Rosenberg updated WW-4514: - Attachment: DefaultUrlHelper.patch Patch with suggested fix. DefaultUrlHelper.buildParametersString appends just ? if collection is empty Key: WW-4514 URL: https://issues.apache.org/jira/browse/WW-4514 Project: Struts 2 Issue Type: Bug Components: Core Actions Affects Versions: 2.3.24 Reporter: Jasper Rosenberg Priority: Trivial Attachments: DefaultUrlHelper.patch DefaultUrlHelper.buildParametersString() checks that it has parameters to append before adding the first ?/, but if the only parameters are empty Iterables/Arrays, then it shouldn't do that. I'd suggest adding the new query string to a StringBuilder, and then if it is non-empty, append that with the separator to the link at the end. (See patch) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WW-4514) DefaultUrlHelper.buildParametersString appends just ? if collection is empty
Jasper Rosenberg created WW-4514: Summary: DefaultUrlHelper.buildParametersString appends just ? if collection is empty Key: WW-4514 URL: https://issues.apache.org/jira/browse/WW-4514 Project: Struts 2 Issue Type: Bug Components: Core Actions Affects Versions: 2.3.24 Reporter: Jasper Rosenberg Priority: Trivial Attachments: DefaultUrlHelper.patch DefaultUrlHelper.buildParametersString() checks that it has parameters to append before adding the first ?/, but if the only parameters are empty Iterables/Arrays, then it shouldn't do that. I'd suggest adding the new query string to a StringBuilder, and then if it is non-empty, append that with the separator to the link at the end. (See patch) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (WW-4514) DefaultUrlHelper.buildParametersString appends just ? if collection is empty
[ https://issues.apache.org/jira/browse/WW-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583383#comment-14583383 ] Jasper Rosenberg edited comment on WW-4514 at 6/12/15 1:34 PM: --- Patch with suggested fix. Also includes updates to unit test to test empty and non-empty list parameters. was (Author: perfnorm): Patch with suggested fix. DefaultUrlHelper.buildParametersString appends just ? if collection is empty Key: WW-4514 URL: https://issues.apache.org/jira/browse/WW-4514 Project: Struts 2 Issue Type: Bug Components: Core Actions Affects Versions: 2.3.24 Reporter: Jasper Rosenberg Priority: Trivial Attachments: DefaultUrlHelper.patch DefaultUrlHelper.buildParametersString() checks that it has parameters to append before adding the first ?/, but if the only parameters are empty Iterables/Arrays, then it shouldn't do that. I'd suggest adding the new query string to a StringBuilder, and then if it is non-empty, append that with the separator to the link at the end. (See patch) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4475) OgnlValueStackFactory.setContainer() has unused local variable
[
https://issues.apache.org/jira/browse/WW-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550752#comment-14550752
]
Jasper Rosenberg commented on WW-4475:
--
Yes, I had to extend it which is how I noticed it. :)
OgnlValueStackFactory.setContainer() has unused local variable
--
Key: WW-4475
URL: https://issues.apache.org/jira/browse/WW-4475
Project: Struts 2
Issue Type: Bug
Components: Core Actions
Reporter: Jasper Rosenberg
Priority: Minor
Labels: ognl
Fix For: 2.5
Not sure of the intent, but this code appears to do nothing...
{code:java}
if (Map.class.isAssignableFrom(cls)) {
PropertyAccessor acc = container.getInstance(PropertyAccessor.class,
name);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4493) Still can't pass parameters with dashes to tags
[
https://issues.apache.org/jira/browse/WW-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521367#comment-14521367
]
Jasper Rosenberg commented on WW-4493:
--
Awesome, just let me know when there is a release candidate I can test, thanks!
Still can't pass parameters with dashes to tags
---
Key: WW-4493
URL: https://issues.apache.org/jira/browse/WW-4493
Project: Struts 2
Issue Type: Bug
Components: Expression Language
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Assignee: Lukasz Lenart
Priority: Minor
Labels: freemarker, tags
Fix For: 2.3.24
The latest freemarker now supports dashes in attribute names, so I can write
something like:
{code:xml}
@s.form name=sendToPhone data\-ajax=false
/@s.form
{code}
Unfortunately, the parameters are set using ognl internally, so it blows up
with an error like:
{noformat}
Caused by: ognl.InappropriateExpressionException: Inappropriate OGNL
expression: data - ajax
at ognl.SimpleNode.setValueBody(SimpleNode.java:312)
at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220)
at ognl.SimpleNode.setValue(SimpleNode.java:301)
at ognl.Ognl.setValue(Ognl.java:737)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:287)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:282)
at
com.opensymphony.xwork2.ognl.OgnlUtil.compileAndExecute(OgnlUtil.java:340)
at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:282)
{noformat}
I think there is a simple solution, which is to send any parameters with an
dash directly to the parameters map like so:
{code:title=Component.java|borderStyle=solid}
/**
* Pushes this component's parameter Map as well as the component itself
on to the stack
* and then copies the supplied parameters over. Because the component's
parameter Map is
* pushed before the component itself, any key-value pair that can't be
assigned to component
* will be set in the parameters Map.
*
* @param params the parameters to copy.
*/
public void copyParams(Map params) {
stack.push(parameters);
stack.push(this);
try {
for (Object o : params.entrySet()) {
Map.Entry entry = (Map.Entry) o;
String key = (String) entry.getKey();
if (key.indexOf('-') = 0) {
// UI component attributes may contain hypens (e.g.
data-ajax), but ognl
// can't handle that, and there can't be a component
property with a hypen
// so into the parameters map it goes.
parameters.put(key, entry.getValue());
} else {
stack.setValue(key, entry.getValue());
}
}
} finally {
stack.pop();
stack.pop();
}
}
{code}
Hoping this can make it into 2.3.24, thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4493) Still can't pass parameters with dashes to tags
[
https://issues.apache.org/jira/browse/WW-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14519192#comment-14519192
]
Jasper Rosenberg commented on WW-4493:
--
Okay, I figured out why it doesn't work for me, but it is working for everyone
else. I have my struts configured to propagate OgnlExceptions. By default they
are swallowed, so the exception I showed in the original bug report is dropped
and the rendering continues just fine (I verified this by turning off the
propagation of OgnlExceptions locally).
You can verify it by putting a breakpoint in
OgnlValueStack.handleOgnlException(), and you will see that the only reason it
is working for you is that throwExceptionOnFailure is false.
My patch above will remove this as an issue for those of us who want to see
OgnlExceptions (when I turned this on I found a lot of bugs in our code that
had been previously masked.)
Thanks!
Still can't pass parameters with dashes to tags
---
Key: WW-4493
URL: https://issues.apache.org/jira/browse/WW-4493
Project: Struts 2
Issue Type: Bug
Components: Expression Language
Affects Versions: 2.3.23
Reporter: Jasper Rosenberg
Priority: Minor
Labels: freemarker, tags
Fix For: 2.3.24
The latest freemarker now supports dashes in attribute names, so I can write
something like:
{code:xml}
@s.form name=sendToPhone data\-ajax=false
/@s.form
{code}
Unfortunately, the parameters are set using ognl internally, so it blows up
with an error like:
{noformat}
Caused by: ognl.InappropriateExpressionException: Inappropriate OGNL
expression: data - ajax
at ognl.SimpleNode.setValueBody(SimpleNode.java:312)
at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220)
at ognl.SimpleNode.setValue(SimpleNode.java:301)
at ognl.Ognl.setValue(Ognl.java:737)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:287)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:282)
at
com.opensymphony.xwork2.ognl.OgnlUtil.compileAndExecute(OgnlUtil.java:340)
at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:282)
{noformat}
I think there is a simple solution, which is to send any parameters with an
dash directly to the parameters map like so:
{code:title=Component.java|borderStyle=solid}
/**
* Pushes this component's parameter Map as well as the component itself
on to the stack
* and then copies the supplied parameters over. Because the component's
parameter Map is
* pushed before the component itself, any key-value pair that can't be
assigned to component
* will be set in the parameters Map.
*
* @param params the parameters to copy.
*/
public void copyParams(Map params) {
stack.push(parameters);
stack.push(this);
try {
for (Object o : params.entrySet()) {
Map.Entry entry = (Map.Entry) o;
String key = (String) entry.getKey();
if (key.indexOf('-') = 0) {
// UI component attributes may contain hypens (e.g.
data-ajax), but ognl
// can't handle that, and there can't be a component
property with a hypen
// so into the parameters map it goes.
parameters.put(key, entry.getValue());
} else {
stack.setValue(key, entry.getValue());
}
}
} finally {
stack.pop();
stack.pop();
}
}
{code}
Hoping this can make it into 2.3.24, thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4493) Still can't pass parameters with dashes to tags
[
https://issues.apache.org/jira/browse/WW-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510147#comment-14510147
]
Jasper Rosenberg commented on WW-4493:
--
Unfortunately, I can't right now. Can you please post a comment with just the
snippet of your sample freemarker code that is using an attribute with a dash
in a struts tag successfully? Thanks!
Still can't pass parameters with dashes to tags
---
Key: WW-4493
URL: https://issues.apache.org/jira/browse/WW-4493
Project: Struts 2
Issue Type: Bug
Components: Expression Language
Affects Versions: 2.3.23
Reporter: Jasper Rosenberg
Priority: Minor
Labels: freemarker, tags
Fix For: 2.3.24
The latest freemarker now supports dashes in attribute names, so I can write
something like:
{code:xml}
@s.form name=sendToPhone data\-ajax=false
/@s.form
{code}
Unfortunately, the parameters are set using ognl internally, so it blows up
with an error like:
{noformat}
Caused by: ognl.InappropriateExpressionException: Inappropriate OGNL
expression: data - ajax
at ognl.SimpleNode.setValueBody(SimpleNode.java:312)
at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220)
at ognl.SimpleNode.setValue(SimpleNode.java:301)
at ognl.Ognl.setValue(Ognl.java:737)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:287)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:282)
at
com.opensymphony.xwork2.ognl.OgnlUtil.compileAndExecute(OgnlUtil.java:340)
at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:282)
{noformat}
I think there is a simple solution, which is to send any parameters with an
dash directly to the parameters map like so:
{code:title=Component.java|borderStyle=solid}
/**
* Pushes this component's parameter Map as well as the component itself
on to the stack
* and then copies the supplied parameters over. Because the component's
parameter Map is
* pushed before the component itself, any key-value pair that can't be
assigned to component
* will be set in the parameters Map.
*
* @param params the parameters to copy.
*/
public void copyParams(Map params) {
stack.push(parameters);
stack.push(this);
try {
for (Object o : params.entrySet()) {
Map.Entry entry = (Map.Entry) o;
String key = (String) entry.getKey();
if (key.indexOf('-') = 0) {
// UI component attributes may contain hypens (e.g.
data-ajax), but ognl
// can't handle that, and there can't be a component
property with a hypen
// so into the parameters map it goes.
parameters.put(key, entry.getValue());
} else {
stack.setValue(key, entry.getValue());
}
}
} finally {
stack.pop();
stack.pop();
}
}
{code}
Hoping this can make it into 2.3.24, thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4493) Still can't pass parameters with dashes to tags
[
https://issues.apache.org/jira/browse/WW-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508914#comment-14508914
]
Jasper Rosenberg commented on WW-4493:
--
Can you try with 2.3.23. Perhaps the way the parameters map is built was
changed?
Also, not sure it is safe for a point release to bump freemarker up to the
latest non-backwards compatible setting by default. A user can control this
themselves via the freemarker.properties.
Still can't pass parameters with dashes to tags
---
Key: WW-4493
URL: https://issues.apache.org/jira/browse/WW-4493
Project: Struts 2
Issue Type: Bug
Components: Expression Language
Affects Versions: 2.3.23
Reporter: Jasper Rosenberg
Priority: Minor
Labels: freemarker, tags
Fix For: 2.3.24
The latest freemarker now supports dashes in attribute names, so I can write
something like:
{code:xml}
@s.form name=sendToPhone data\-ajax=false
/@s.form
{code}
Unfortunately, the parameters are set using ognl internally, so it blows up
with an error like:
{noformat}
Caused by: ognl.InappropriateExpressionException: Inappropriate OGNL
expression: data - ajax
at ognl.SimpleNode.setValueBody(SimpleNode.java:312)
at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220)
at ognl.SimpleNode.setValue(SimpleNode.java:301)
at ognl.Ognl.setValue(Ognl.java:737)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:287)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:282)
at
com.opensymphony.xwork2.ognl.OgnlUtil.compileAndExecute(OgnlUtil.java:340)
at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:282)
{noformat}
I think there is a simple solution, which is to send any parameters with an
dash directly to the parameters map like so:
{code:title=Component.java|borderStyle=solid}
/**
* Pushes this component's parameter Map as well as the component itself
on to the stack
* and then copies the supplied parameters over. Because the component's
parameter Map is
* pushed before the component itself, any key-value pair that can't be
assigned to component
* will be set in the parameters Map.
*
* @param params the parameters to copy.
*/
public void copyParams(Map params) {
stack.push(parameters);
stack.push(this);
try {
for (Object o : params.entrySet()) {
Map.Entry entry = (Map.Entry) o;
String key = (String) entry.getKey();
if (key.indexOf('-') = 0) {
// UI component attributes may contain hypens (e.g.
data-ajax), but ognl
// can't handle that, and there can't be a component
property with a hypen
// so into the parameters map it goes.
parameters.put(key, entry.getValue());
} else {
stack.setValue(key, entry.getValue());
}
}
} finally {
stack.pop();
stack.pop();
}
}
{code}
Hoping this can make it into 2.3.24, thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WW-4493) Still can't pass parameters with dashes to tags
Jasper Rosenberg created WW-4493:
Summary: Still can't pass parameters with dashes to tags
Key: WW-4493
URL: https://issues.apache.org/jira/browse/WW-4493
Project: Struts 2
Issue Type: Bug
Components: Expression Language
Affects Versions: 2.3.23
Reporter: Jasper Rosenberg
Priority: Minor
The latest freemarker now supports dashes in attribute names, so I can write
something like:
{code:xml}
@s.form name=sendToPhone data\-ajax=false
/@s.form
{code}
Unfortunately, the parameters are set using ognl internally, so it blows up
with an error like:
{noformat}
Caused by: ognl.InappropriateExpressionException: Inappropriate OGNL
expression: data - ajax
at ognl.SimpleNode.setValueBody(SimpleNode.java:312)
at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220)
at ognl.SimpleNode.setValue(SimpleNode.java:301)
at ognl.Ognl.setValue(Ognl.java:737)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:287)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:282)
at
com.opensymphony.xwork2.ognl.OgnlUtil.compileAndExecute(OgnlUtil.java:340)
at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:282)
{noformat}
I think there is a simple solution, which is to send any parameters with an
dash directly to the parameters map like so:
{code:title=Component.java|borderStyle=solid}
/**
* Pushes this component's parameter Map as well as the component itself on
to the stack
* and then copies the supplied parameters over. Because the component's
parameter Map is
* pushed before the component itself, any key-value pair that can't be
assigned to component
* will be set in the parameters Map.
*
* @param params the parameters to copy.
*/
public void copyParams(Map params) {
stack.push(parameters);
stack.push(this);
try {
for (Object o : params.entrySet()) {
Map.Entry entry = (Map.Entry) o;
String key = (String) entry.getKey();
if (key.indexOf('-') = 0) {
// UI component attributes may contain hypens (e.g.
data-ajax), but ognl
// can't handle that, and there can't be a component
property with a hypen
// so into the parameters map it goes.
parameters.put(key, entry.getValue());
} else {
stack.setValue(key, entry.getValue());
}
}
} finally {
stack.pop();
stack.pop();
}
}
{code}
Hoping this can make it into 2.3.24, thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (WW-4493) Still can't pass parameters with dashes to tags
[
https://issues.apache.org/jira/browse/WW-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14506280#comment-14506280
]
Jasper Rosenberg edited comment on WW-4493 at 4/22/15 2:37 AM:
---
Not sure what you are saying [~quaff], you mean it works with my patch, or you
can get struts tags with dashes to work w/o the patch. (I'm pretty sure it is
not the later)
was (Author: perfnorm):
Not sure what you are saying [~quaff], you mean it works with my patch, or you
can get struts tags with dashes to work w/o the patch.
Still can't pass parameters with dashes to tags
---
Key: WW-4493
URL: https://issues.apache.org/jira/browse/WW-4493
Project: Struts 2
Issue Type: Bug
Components: Expression Language
Affects Versions: 2.3.23
Reporter: Jasper Rosenberg
Priority: Minor
Labels: freemarker, tags
The latest freemarker now supports dashes in attribute names, so I can write
something like:
{code:xml}
@s.form name=sendToPhone data\-ajax=false
/@s.form
{code}
Unfortunately, the parameters are set using ognl internally, so it blows up
with an error like:
{noformat}
Caused by: ognl.InappropriateExpressionException: Inappropriate OGNL
expression: data - ajax
at ognl.SimpleNode.setValueBody(SimpleNode.java:312)
at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220)
at ognl.SimpleNode.setValue(SimpleNode.java:301)
at ognl.Ognl.setValue(Ognl.java:737)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:287)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:282)
at
com.opensymphony.xwork2.ognl.OgnlUtil.compileAndExecute(OgnlUtil.java:340)
at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:282)
{noformat}
I think there is a simple solution, which is to send any parameters with an
dash directly to the parameters map like so:
{code:title=Component.java|borderStyle=solid}
/**
* Pushes this component's parameter Map as well as the component itself
on to the stack
* and then copies the supplied parameters over. Because the component's
parameter Map is
* pushed before the component itself, any key-value pair that can't be
assigned to component
* will be set in the parameters Map.
*
* @param params the parameters to copy.
*/
public void copyParams(Map params) {
stack.push(parameters);
stack.push(this);
try {
for (Object o : params.entrySet()) {
Map.Entry entry = (Map.Entry) o;
String key = (String) entry.getKey();
if (key.indexOf('-') = 0) {
// UI component attributes may contain hypens (e.g.
data-ajax), but ognl
// can't handle that, and there can't be a component
property with a hypen
// so into the parameters map it goes.
parameters.put(key, entry.getValue());
} else {
stack.setValue(key, entry.getValue());
}
}
} finally {
stack.pop();
stack.pop();
}
}
{code}
Hoping this can make it into 2.3.24, thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4493) Still can't pass parameters with dashes to tags
[
https://issues.apache.org/jira/browse/WW-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14506280#comment-14506280
]
Jasper Rosenberg commented on WW-4493:
--
Not sure what you are saying [~quaff], you mean it works with my patch, or you
can get struts tags with dashes to work w/o the patch.
Still can't pass parameters with dashes to tags
---
Key: WW-4493
URL: https://issues.apache.org/jira/browse/WW-4493
Project: Struts 2
Issue Type: Bug
Components: Expression Language
Affects Versions: 2.3.23
Reporter: Jasper Rosenberg
Priority: Minor
Labels: freemarker, tags
The latest freemarker now supports dashes in attribute names, so I can write
something like:
{code:xml}
@s.form name=sendToPhone data\-ajax=false
/@s.form
{code}
Unfortunately, the parameters are set using ognl internally, so it blows up
with an error like:
{noformat}
Caused by: ognl.InappropriateExpressionException: Inappropriate OGNL
expression: data - ajax
at ognl.SimpleNode.setValueBody(SimpleNode.java:312)
at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220)
at ognl.SimpleNode.setValue(SimpleNode.java:301)
at ognl.Ognl.setValue(Ognl.java:737)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:287)
at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:282)
at
com.opensymphony.xwork2.ognl.OgnlUtil.compileAndExecute(OgnlUtil.java:340)
at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:282)
{noformat}
I think there is a simple solution, which is to send any parameters with an
dash directly to the parameters map like so:
{code:title=Component.java|borderStyle=solid}
/**
* Pushes this component's parameter Map as well as the component itself
on to the stack
* and then copies the supplied parameters over. Because the component's
parameter Map is
* pushed before the component itself, any key-value pair that can't be
assigned to component
* will be set in the parameters Map.
*
* @param params the parameters to copy.
*/
public void copyParams(Map params) {
stack.push(parameters);
stack.push(this);
try {
for (Object o : params.entrySet()) {
Map.Entry entry = (Map.Entry) o;
String key = (String) entry.getKey();
if (key.indexOf('-') = 0) {
// UI component attributes may contain hypens (e.g.
data-ajax), but ognl
// can't handle that, and there can't be a component
property with a hypen
// so into the parameters map it goes.
parameters.put(key, entry.getValue());
} else {
stack.setValue(key, entry.getValue());
}
}
} finally {
stack.pop();
stack.pop();
}
}
{code}
Hoping this can make it into 2.3.24, thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4486) Default parameter exclusions blocking legitimate values
[
https://issues.apache.org/jira/browse/WW-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14494485#comment-14494485
]
Jasper Rosenberg commented on WW-4486:
--
Just want to reiterate how absurd this situation is right now. We just had a
legitimate user try to log in to the site and fail (and then try to do a forgot
password and fail) because their email address looked like:
class.supersa...@yahoo.com
Default parameter exclusions blocking legitimate values
---
Key: WW-4486
URL: https://issues.apache.org/jira/browse/WW-4486
Project: Struts 2
Issue Type: Bug
Components: Core Interceptors
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Critical
Fix For: 2.5
In ParametersInterceptor.setParameters(), when building
acceptableParameters(), it applies the check isAcceptableValue not just just
to the parameter name, but also to the parameter value. This is a huge
problem because the default excludedPatterns include phrases that will come
up in normal user form submissions.
For example, the way I discovered this is that one pattern is
(.*\.|^|.*|\[('|))\bclass(\.|('|)]|\[).*
We are a car site, so when a user tried to post a message about a Mercedes M
class: That's M class. You asked for G class, different beast!
The class. at the end of the first sentence was rejected and so their post
failed.
What is the reason for applying the exclusion patterns wholesale to the
parameter value? Is it even necessary at all, or is there some kind of
escape character that normally tells ognl to evaluate an expression in the
value, in which case we could check for exclusion pattern matches just within
those?
As it is though, the current solution is going to cause some occasional very
peculiar behavior for developers. Not sure if this should actually be a
blocker bug since the only reasonable workaround seems to be to hack the
ParametersInterceptor locally (since one shouldn't remove the exclusion
patterns in general).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4489) Simplify DefaultExcludedPatternsChecker class pattern
[
https://issues.apache.org/jira/browse/WW-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14487258#comment-14487258
]
Jasper Rosenberg commented on WW-4489:
--
If I remove it, the unit test fails on test pattern:
{code}form[class][classLoader]{code}
Simplify DefaultExcludedPatternsChecker class pattern
-
Key: WW-4489
URL: https://issues.apache.org/jira/browse/WW-4489
Project: Struts 2
Issue Type: Bug
Components: Core Interceptors
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Minor
Fix For: 2.3.24
The current pattern that matches class expressions looks like:
{code:java}(.*\\.|^|.*|\\[('|\))\\bclass(\\.|('|\)]|\\[).*{code}
However, as far as I can tell, this is completely equivalent to:
{code:java}.*\\bclass(\\.|('|\)]|\\[).*{code}
Not sure if this is a bug, or an improvement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WW-4489) Simplify DefaultExcludedPatternsChecker class pattern
Jasper Rosenberg created WW-4489:
Summary: Simplify DefaultExcludedPatternsChecker class pattern
Key: WW-4489
URL: https://issues.apache.org/jira/browse/WW-4489
Project: Struts 2
Issue Type: Bug
Components: Core Interceptors
Affects Versions: 2.3.23, 2.3.20
Reporter: Jasper Rosenberg
Priority: Minor
The current pattern that matches class expressions looks like:
{code:java}(.*\\.|^|.*|\\[('|\))\\bclass(\\.|('|\)]|\\[).*{code}
However, as far as I can tell, this is completely equivalent to:
{code:java}.*\\bclass(\\.|('|\)]|\\[).*{code}
Not sure if this is a bug, or an improvement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (WW-4489) Simplify DefaultExcludedPatternsChecker class pattern
[
https://issues.apache.org/jira/browse/WW-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14487234#comment-14487234
]
Jasper Rosenberg edited comment on WW-4489 at 4/9/15 11:58 AM:
---
Well, all I was trying to point out is that the current pattern matches
anything before {noformat}\\bclass{noformat} because of the |.*| section. I
figured that wasn't intentional, but wasn't sure what the intent was.
was (Author: perfnorm):
Well, all I was trying to point out is that the current pattern matches
anything before \\bclass, because of the |.*| section. I figured that wasn't
intentional, but wasn't sure what the intent was.
Simplify DefaultExcludedPatternsChecker class pattern
-
Key: WW-4489
URL: https://issues.apache.org/jira/browse/WW-4489
Project: Struts 2
Issue Type: Bug
Components: Core Interceptors
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Minor
Fix For: 2.3.24
The current pattern that matches class expressions looks like:
{code:java}(.*\\.|^|.*|\\[('|\))\\bclass(\\.|('|\)]|\\[).*{code}
However, as far as I can tell, this is completely equivalent to:
{code:java}.*\\bclass(\\.|('|\)]|\\[).*{code}
Not sure if this is a bug, or an improvement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WW-4488) Improve performance of DefaultExcludedPatternsChecker
Jasper Rosenberg created WW-4488:
Summary: Improve performance of DefaultExcludedPatternsChecker
Key: WW-4488
URL: https://issues.apache.org/jira/browse/WW-4488
Project: Struts 2
Issue Type: Improvement
Components: Core Interceptors
Affects Versions: 2.3.23, 2.3.20
Reporter: Jasper Rosenberg
Priority: Trivial
The current set of patterns can be consolidated without sacrificing readability
for a significant gain in efficiency. I ran both sets of equivalent patterns
against the three test methods in DefaultExcludedPatternsCheckerTest 100,000
times, and the consolidated pattern was 3 times faster.
{code:java}
public static final String[] EXCLUDED_PATTERNS = {
(.*\\.|^|.*|\\[('|\))\\bclass(\\.|('|\)]|\\[).*,
(^|.*#)(dojo|struts|session|request|application|servlet(Request|Response)
+ |parameters|context|_memberAccess)(\\.|\\[).*
};
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WW-4486) Default parameter exclusions blocking legitimate values
Jasper Rosenberg created WW-4486:
Summary: Default parameter exclusions blocking legitimate values
Key: WW-4486
URL: https://issues.apache.org/jira/browse/WW-4486
Project: Struts 2
Issue Type: Bug
Components: Core Interceptors
Affects Versions: 2.3.23
Reporter: Jasper Rosenberg
Priority: Critical
In ParametersInterceptor.setParameters(), when building acceptableParameters(),
it applies the check isAcceptableValue not just just to the parameter name, but
also to the parameter value. This is a huge problem because the default
excludedPatterns include phrases that will come up in normal user form
submissions.
For example, the way I discovered this is that one pattern is
(.*\.|^|.*|\[('|))\bclass(\.|('|)]|\[).*
We are a car site, so when a user tried to post a message about a Mercedes M
class: That's M class. You asked for G class, different beast!
The class. at the end of the first sentence was rejected and so their post
failed.
What is the reason for applying the exclusion patterns wholesale to the
parameter value? Is it even necessary at all, or is there some kind of escape
character that normally tells ognl to evaluate an expression in the value, in
which case we could check for exclusion pattern matches just within those?
As it is though, the current solution is going to cause some occasional very
peculiar behavior for developers. Not sure if this should actually be a
blocker bug since the only reasonable workaround seems to be to hack the
ParametersInterceptor locally (since one shouldn't remove the exclusion
patterns in general).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4486) Default parameter exclusions blocking legitimate values
[
https://issues.apache.org/jira/browse/WW-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14485174#comment-14485174
]
Jasper Rosenberg commented on WW-4486:
--
Wow, that is problematic to say the least. Is there a discussion somewhere I
can look at which talks about the specific spots where double evaluation can
happen? I'm guessing the ConversionErrorInterceptor is one of them. I can't
seem to reproduce setting a value and having ognl evaluate it on the way in
though. By any chance do you have a sample expression that i should be able to
pass in as a value to a struts textfield tag and see ognl try to evaluate it?
Thanks!
Default parameter exclusions blocking legitimate values
---
Key: WW-4486
URL: https://issues.apache.org/jira/browse/WW-4486
Project: Struts 2
Issue Type: Bug
Components: Core Interceptors
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Critical
Fix For: 2.5
In ParametersInterceptor.setParameters(), when building
acceptableParameters(), it applies the check isAcceptableValue not just just
to the parameter name, but also to the parameter value. This is a huge
problem because the default excludedPatterns include phrases that will come
up in normal user form submissions.
For example, the way I discovered this is that one pattern is
(.*\.|^|.*|\[('|))\bclass(\.|('|)]|\[).*
We are a car site, so when a user tried to post a message about a Mercedes M
class: That's M class. You asked for G class, different beast!
The class. at the end of the first sentence was rejected and so their post
failed.
What is the reason for applying the exclusion patterns wholesale to the
parameter value? Is it even necessary at all, or is there some kind of
escape character that normally tells ognl to evaluate an expression in the
value, in which case we could check for exclusion pattern matches just within
those?
As it is though, the current solution is going to cause some occasional very
peculiar behavior for developers. Not sure if this should actually be a
blocker bug since the only reasonable workaround seems to be to hack the
ParametersInterceptor locally (since one shouldn't remove the exclusion
patterns in general).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4486) Default parameter exclusions blocking legitimate values
[
https://issues.apache.org/jira/browse/WW-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14485202#comment-14485202
]
Jasper Rosenberg commented on WW-4486:
--
You could tell me, but then you'd have to kill me? ;)
Default parameter exclusions blocking legitimate values
---
Key: WW-4486
URL: https://issues.apache.org/jira/browse/WW-4486
Project: Struts 2
Issue Type: Bug
Components: Core Interceptors
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Critical
Fix For: 2.5
In ParametersInterceptor.setParameters(), when building
acceptableParameters(), it applies the check isAcceptableValue not just just
to the parameter name, but also to the parameter value. This is a huge
problem because the default excludedPatterns include phrases that will come
up in normal user form submissions.
For example, the way I discovered this is that one pattern is
(.*\.|^|.*|\[('|))\bclass(\.|('|)]|\[).*
We are a car site, so when a user tried to post a message about a Mercedes M
class: That's M class. You asked for G class, different beast!
The class. at the end of the first sentence was rejected and so their post
failed.
What is the reason for applying the exclusion patterns wholesale to the
parameter value? Is it even necessary at all, or is there some kind of
escape character that normally tells ognl to evaluate an expression in the
value, in which case we could check for exclusion pattern matches just within
those?
As it is though, the current solution is going to cause some occasional very
peculiar behavior for developers. Not sure if this should actually be a
blocker bug since the only reasonable workaround seems to be to hack the
ParametersInterceptor locally (since one shouldn't remove the exclusion
patterns in general).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4485) New cacheKey is too expensive to create
[
https://issues.apache.org/jira/browse/WW-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14482931#comment-14482931
]
Jasper Rosenberg commented on WW-4485:
--
Thanks, I will get right on testing it.
Also, as an aside, I realized that there actually was a regression issue
introduced by WW-4113 as well. Before, if a class had been loaded by different
class loaders, then it was cached twice in ognl, which I think is the safest
behavior. After WW-4113, because it was using the class's name, the same class
name from different class loaders would be only cached once, with the first one
in winning.
New cacheKey is too expensive to create
---
Key: WW-4485
URL: https://issues.apache.org/jira/browse/WW-4485
Project: Struts 2
Issue Type: Bug
Components: Core Actions, Expression Language
Reporter: Jasper Rosenberg
Priority: Blocker
Labels: ognl
Fix For: 2.5
So we pushed ognl 3.0.10 to production this afternoon, and promptly had to
rollback because load on the servers went through the roof. Looking at the
stack traces, the issue was tons of threads doing this:
{noformat}
at java.lang.Class.getEnclosingMethod0(Native Method)
at java.lang.Class.getEnclosingMethodInfo(Class.java:1059)
at java.lang.Class.isLocalOrAnonymousClass(Class.java:1449)
at java.lang.Class.getCanonicalName(Class.java:1377)
at ognl.OgnlRuntime.buildCacheKey(OgnlRuntime.java:1944)
at ognl.OgnlRuntime.getGetMethod(OgnlRuntime.java:1926)
at ognl.OgnlRuntime.hasGetMethod(OgnlRuntime.java:1985)
at ognl.OgnlRuntime.hasGetProperty(OgnlRuntime.java:2045)
at
com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.getProperty(CompoundRootAccessor.java:141)
{noformat}
The problem is that the change to buildCacheKey() for
https://issues.apache.org/jira/browse/WW-4113 is way to expensive considering
how often it is called.
I'd like to suggest replacing the current buildCacheKey() implementation with
this:
{code:java}
private static Object buildCacheKey(Class targetClass, String
propertyName) {
return new CacheKey(targetClass, propertyName);
}
private static final class CacheKey {
private final Class clazz;
private final String propertyName;
public CacheKey(Class clazz, String propertyName) {
this.clazz = clazz;
this.propertyName = propertyName;
}
public boolean equals(Object obj) {
CacheKey cacheKey = (CacheKey) obj;
return clazz.equals(cacheKey.clazz)
propertyName.equals(cacheKey.propertyName);
}
public int hashCode() {
return clazz.hashCode() * 31 + propertyName.hashCode();
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4485) New cacheKey is too expensive to create
[
https://issues.apache.org/jira/browse/WW-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14482989#comment-14482989
]
Jasper Rosenberg commented on WW-4485:
--
Awesome, I really appreciate you making time for this so quickly.
New cacheKey is too expensive to create
---
Key: WW-4485
URL: https://issues.apache.org/jira/browse/WW-4485
Project: Struts 2
Issue Type: Bug
Components: Core Actions, Expression Language
Reporter: Jasper Rosenberg
Assignee: Lukasz Lenart
Priority: Blocker
Labels: ognl
Fix For: 2.5
So we pushed ognl 3.0.10 to production this afternoon, and promptly had to
rollback because load on the servers went through the roof. Looking at the
stack traces, the issue was tons of threads doing this:
{noformat}
at java.lang.Class.getEnclosingMethod0(Native Method)
at java.lang.Class.getEnclosingMethodInfo(Class.java:1059)
at java.lang.Class.isLocalOrAnonymousClass(Class.java:1449)
at java.lang.Class.getCanonicalName(Class.java:1377)
at ognl.OgnlRuntime.buildCacheKey(OgnlRuntime.java:1944)
at ognl.OgnlRuntime.getGetMethod(OgnlRuntime.java:1926)
at ognl.OgnlRuntime.hasGetMethod(OgnlRuntime.java:1985)
at ognl.OgnlRuntime.hasGetProperty(OgnlRuntime.java:2045)
at
com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.getProperty(CompoundRootAccessor.java:141)
{noformat}
The problem is that the change to buildCacheKey() for
https://issues.apache.org/jira/browse/WW-4113 is way to expensive considering
how often it is called.
I'd like to suggest replacing the current buildCacheKey() implementation with
this:
{code:java}
private static Object buildCacheKey(Class targetClass, String
propertyName) {
return new CacheKey(targetClass, propertyName);
}
private static final class CacheKey {
private final Class clazz;
private final String propertyName;
public CacheKey(Class clazz, String propertyName) {
this.clazz = clazz;
this.propertyName = propertyName;
}
public boolean equals(Object obj) {
CacheKey cacheKey = (CacheKey) obj;
return clazz.equals(cacheKey.clazz)
propertyName.equals(cacheKey.propertyName);
}
public int hashCode() {
return clazz.hashCode() * 31 + propertyName.hashCode();
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4462) Regression bug in ognl for is... property getters
[
https://issues.apache.org/jira/browse/WW-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14394300#comment-14394300
]
Jasper Rosenberg commented on WW-4462:
--
Yeah, it is right there. For some reason the README.md file that is in the
ognl-OGNL_3_0_9.zip file only goes through 3.0.8
Regression bug in ognl for is... property getters
---
Key: WW-4462
URL: https://issues.apache.org/jira/browse/WW-4462
Project: Struts 2
Issue Type: Bug
Components: Core Actions
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Critical
Labels: ognl
Fix For: 2.5
We have a lot of getters on our actions that look like:
public boolean getIsTruck() {
return isTruck;
}
That lets us write ftl that looks like:
#if isTruck.../#if
However, this support was broken in a recent ognl release, I believe by this
patch:
https://github.com/jkuhnert/ognl/commit/6fb948c8a4528546e6e24750f09a89b6a730e17a
I don't see any reason why this pattern shouldn't be supported, so I'm
assuming it is a bug.
This is also keeping us from being able to upgrade to the latest ognl which
has some critical fixes we were really hoping to take advantage of.
Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4462) Regression bug in ognl for is... property getters
[
https://issues.apache.org/jira/browse/WW-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14394339#comment-14394339
]
Jasper Rosenberg commented on WW-4462:
--
Just tried the 3.0.10 snapshot, and it worked great. Thanks!
Regression bug in ognl for is... property getters
---
Key: WW-4462
URL: https://issues.apache.org/jira/browse/WW-4462
Project: Struts 2
Issue Type: Bug
Components: Core Actions
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Critical
Labels: ognl
Fix For: 2.5
We have a lot of getters on our actions that look like:
public boolean getIsTruck() {
return isTruck;
}
That lets us write ftl that looks like:
#if isTruck.../#if
However, this support was broken in a recent ognl release, I believe by this
patch:
https://github.com/jkuhnert/ognl/commit/6fb948c8a4528546e6e24750f09a89b6a730e17a
I don't see any reason why this pattern shouldn't be supported, so I'm
assuming it is a bug.
This is also keeping us from being able to upgrade to the latest ognl which
has some critical fixes we were really hoping to take advantage of.
Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4462) Regression bug in ognl for is... property getters
[
https://issues.apache.org/jira/browse/WW-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392529#comment-14392529
]
Jasper Rosenberg commented on WW-4462:
--
Maybe there should be an ognl branch with just the thread safety/hashing fixes
that actually goes out with the next struts2 core release (since everyone need
it), and the patch that is a regression risk (how bean properties are
interpreted) could be temporarily backed out or split off.
Regression bug in ognl for is... property getters
---
Key: WW-4462
URL: https://issues.apache.org/jira/browse/WW-4462
Project: Struts 2
Issue Type: Bug
Components: Core Actions
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Critical
Labels: ognl
Fix For: 2.5
We have a lot of getters on our actions that look like:
public boolean getIsTruck() {
return isTruck;
}
That lets us write ftl that looks like:
#if isTruck.../#if
However, this support was broken in a recent ognl release, I believe by this
patch:
https://github.com/jkuhnert/ognl/commit/6fb948c8a4528546e6e24750f09a89b6a730e17a
I don't see any reason why this pattern shouldn't be supported, so I'm
assuming it is a bug.
This is also keeping us from being able to upgrade to the latest ognl which
has some critical fixes we were really hoping to take advantage of.
Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4462) Regression bug in ognl for is... property getters
[
https://issues.apache.org/jira/browse/WW-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392524#comment-14392524
]
Jasper Rosenberg commented on WW-4462:
--
Is there anyway this could get fixed for 2.3.23? I really want to upgrade to
the latest ognl (we encountered one of the fixed threading issues in production
again last week), but this is a blocker for me. Thanks for considering it.
Regression bug in ognl for is... property getters
---
Key: WW-4462
URL: https://issues.apache.org/jira/browse/WW-4462
Project: Struts 2
Issue Type: Bug
Components: Core Actions
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Critical
Labels: ognl
Fix For: 2.5
We have a lot of getters on our actions that look like:
public boolean getIsTruck() {
return isTruck;
}
That lets us write ftl that looks like:
#if isTruck.../#if
However, this support was broken in a recent ognl release, I believe by this
patch:
https://github.com/jkuhnert/ognl/commit/6fb948c8a4528546e6e24750f09a89b6a730e17a
I don't see any reason why this pattern shouldn't be supported, so I'm
assuming it is a bug.
This is also keeping us from being able to upgrade to the latest ognl which
has some critical fixes we were really hoping to take advantage of.
Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4482) Conversion annotation ignored for ServletAction parameter
[
https://issues.apache.org/jira/browse/WW-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392521#comment-14392521
]
Jasper Rosenberg commented on WW-4482:
--
Awesome, thanks!
Conversion annotation ignored for ServletAction parameter
-
Key: WW-4482
URL: https://issues.apache.org/jira/browse/WW-4482
Project: Struts 2
Issue Type: Bug
Components: Expression Language, Value Stack
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Assignee: Lukasz Lenart
Priority: Critical
Fix For: 2.3.23
This definitely worked before 2.3.20, but unfortunately I haven’t been able
to track down the actual source of the bug introduced for 2.3.20. My best
guess is that it was introduced when the code was refactored to support
Collections.
Basically I have an Action, with a setter and getter for state that uses a
custom type convertor like so:
{code:java}
/** @return the state. */
@TypeConversion(converter = com.myco.typeconvertor.RegionTypeConvertor)
public RegionI getState() {
return state;
}
{code}
When I submit the action, this type convertor is correctly used to turn the
“state” post parameter into a RegionI object which is injected into the
Action. So far so good.
However, the result looks like:
{code:xml}
result name=selfSignupFlow type=redirectAction
param name=actionNameconfirmAccount/param
param name=streetAddress${streetAddress}/param
param name=city${city}/param
param name=state${state}/param
param name=postalCode${postalCode}/param
...
/result
{code}
And in the latest release, when it evaluates $\{state} it uses the default
type convertor (in this case for an enum because the concrete class is a
USState enum), rather than the com.myco.typeconvertor.RegionTypeConvertor
specified on both the getter and setter for state in the action.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (WW-4462) Regression bug in ognl for is... property getters
[
https://issues.apache.org/jira/browse/WW-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392968#comment-14392968
]
Jasper Rosenberg edited comment on WW-4462 at 4/2/15 5:15 PM:
--
The problem is that https://issues.apache.org/jira/browse/WW-4451 is not in
3.0.6 (also it appears to not be in the readme notes for 3.0.9, though I think
that is where it was fixed)
was (Author: perfnorm):
The problem is that https://issues.apache.org/jira/browse/WW-4451 is not in
3.0.6
Regression bug in ognl for is... property getters
---
Key: WW-4462
URL: https://issues.apache.org/jira/browse/WW-4462
Project: Struts 2
Issue Type: Bug
Components: Core Actions
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Critical
Labels: ognl
Fix For: 2.5
We have a lot of getters on our actions that look like:
public boolean getIsTruck() {
return isTruck;
}
That lets us write ftl that looks like:
#if isTruck.../#if
However, this support was broken in a recent ognl release, I believe by this
patch:
https://github.com/jkuhnert/ognl/commit/6fb948c8a4528546e6e24750f09a89b6a730e17a
I don't see any reason why this pattern shouldn't be supported, so I'm
assuming it is a bug.
This is also keeping us from being able to upgrade to the latest ognl which
has some critical fixes we were really hoping to take advantage of.
Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4462) Regression bug in ognl for is... property getters
[
https://issues.apache.org/jira/browse/WW-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392968#comment-14392968
]
Jasper Rosenberg commented on WW-4462:
--
The problem is that https://issues.apache.org/jira/browse/WW-4451 is not in
3.0.6
Regression bug in ognl for is... property getters
---
Key: WW-4462
URL: https://issues.apache.org/jira/browse/WW-4462
Project: Struts 2
Issue Type: Bug
Components: Core Actions
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Critical
Labels: ognl
Fix For: 2.5
We have a lot of getters on our actions that look like:
public boolean getIsTruck() {
return isTruck;
}
That lets us write ftl that looks like:
#if isTruck.../#if
However, this support was broken in a recent ognl release, I believe by this
patch:
https://github.com/jkuhnert/ognl/commit/6fb948c8a4528546e6e24750f09a89b6a730e17a
I don't see any reason why this pattern shouldn't be supported, so I'm
assuming it is a bug.
This is also keeping us from being able to upgrade to the latest ognl which
has some critical fixes we were really hoping to take advantage of.
Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4481) Deprecated warning gives no context
[ https://issues.apache.org/jira/browse/WW-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386546#comment-14386546 ] Jasper Rosenberg commented on WW-4481: -- Thanks! (Also, for what it is worth, the static invocation I missed was a getter on an Action that was static because it referenced a static member of that action, but was referenced in the template like a normal property). Deprecated warning gives no context --- Key: WW-4481 URL: https://issues.apache.org/jira/browse/WW-4481 Project: Struts 2 Issue Type: Bug Components: Value Stack Affects Versions: 2.3.22 Reporter: Jasper Rosenberg Assignee: Lukasz Lenart Priority: Critical Fix For: 2.3.23 I released 2.3.22 and immediately had my log files fill up with this warning: WARN [SecurityMemberAccess] Support for accessing static methods is deprecated! Please refactor your application! I was surprised because I thought I had actually removed all static references, but I can't find what I missed because this warning has no context. Can you please add the information about the expression being evaluated so I can track down the usage? Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WW-4483) Add Listener for Configuration events
Jasper Rosenberg created WW-4483: Summary: Add Listener for Configuration events Key: WW-4483 URL: https://issues.apache.org/jira/browse/WW-4483 Project: Struts 2 Issue Type: New Feature Components: XML Configuration Affects Versions: 2.3.20 Reporter: Jasper Rosenberg Priority: Minor We have some rules that we enforce on our struts action and package configurations. We currently enforce these by validating the configuration in non-production environments in a DispatcherListener.dispatcherInitialized() implementation. That works great at startup but, in development, I dynamically reload the configuration (say to fix an action definition), DispatcherListener.dispatcherInitialized() is not invoked, and so the configuration I reloaded is not revalidated. It would be great if struts2 supported a ConfigurationListener interface that could listen for at least init complete, and reload complete events. I could see a lot of practical uses for that. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4482) Conversion annotation ignored for ServletAction parameter
[
https://issues.apache.org/jira/browse/WW-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14372705#comment-14372705
]
Jasper Rosenberg commented on WW-4482:
--
Also, I have confirmed this issue for 2.3.22 as well.
Conversion annotation ignored for ServletAction parameter
-
Key: WW-4482
URL: https://issues.apache.org/jira/browse/WW-4482
Project: Struts 2
Issue Type: Bug
Components: Expression Language, Value Stack
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Critical
This definitely worked before 2.3.20, but unfortunately I haven’t been able
to track down the actual source of the bug introduced for 2.3.20. My best
guess is that it was introduced when the code was refactored to support
Collections.
Basically I have an Action, with a setter and getter for state that uses a
custom type convertor like so:
{code:java}
/** @return the state. */
@TypeConversion(converter = com.myco.typeconvertor.RegionTypeConvertor)
public RegionI getState() {
return state;
}
{code}
When I submit the action, this type convertor is correctly used to turn the
“state” post parameter into a RegionI object which is injected into the
Action. So far so good.
However, the result looks like:
{code:xml}
result name=selfSignupFlow type=redirectAction
param name=actionNameconfirmAccount/param
param name=streetAddress${streetAddress}/param
param name=city${city}/param
param name=state${state}/param
param name=postalCode${postalCode}/param
...
/result
{code}
And in the latest release, when it evaluates $\{state} it uses the default
type convertor (in this case for an enum because the concrete class is a
USState enum), rather than the com.myco.typeconvertor.RegionTypeConvertor
specified on both the getter and setter for state in the action.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WW-4482) Conversion annotation ignored for ServletAction parameter
Jasper Rosenberg created WW-4482:
Summary: Conversion annotation ignored for ServletAction parameter
Key: WW-4482
URL: https://issues.apache.org/jira/browse/WW-4482
Project: Struts 2
Issue Type: Bug
Components: Expression Language, Value Stack
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Critical
This definitely worked before 2.3.20, but unfortunately I haven’t been able to
track down the actual source of the bug introduced for 2.3.20. My best guess
is that it was introduced when the code was refactored to support Collections.
Basically I have an Action, with a setter and getter for state that uses a
custom type convertor like so:
{code:java}
/** @return the state. */
@TypeConversion(converter = com.myco.typeconvertor.RegionTypeConvertor)
public RegionI getState() {
return state;
}
{code}
When I submit the action, this type convertor is correctly used to turn the
“state” post parameter into a RegionI object which is injected into the Action.
So far so good.
However, the result looks like:
{code:xml}
result name=selfSignupFlow type=redirectAction
param name=actionNameconfirmAccount/param
param name=streetAddress${streetAddress}/param
param name=city${city}/param
param name=state${state}/param
param name=postalCode${postalCode}/param
...
/result
{code}
And in the latest release, when it evaluates $\{state} it uses the default type
convertor (in this case for an enum because the concrete class is a USState
enum), rather than the com.myco.typeconvertor.RegionTypeConvertor specified on
both the getter and setter for state in the action.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WW-4480) DefaultActionInvocation.invokeAction calls unknownHandlerManager.handleUnknownMethod for any OgnlException
Jasper Rosenberg created WW-4480: Summary: DefaultActionInvocation.invokeAction calls unknownHandlerManager.handleUnknownMethod for any OgnlException Key: WW-4480 URL: https://issues.apache.org/jira/browse/WW-4480 Project: Struts 2 Issue Type: Bug Components: Core Actions Affects Versions: 2.3.20 Reporter: Jasper Rosenberg Priority: Minor In our environment we are allowing method invocation exceptions in ognl to propagate. (This is so we can fail fast if someone tries to write code that invokes a static method) However, DefaultActionInvocation.invokeAction() does not distinguish between an OgnlException because of the method missing, and an OgnlException because the method threw an exception during execution. It calls handleUnknownMethod in both cases. Instead of just checking for OgnlException it should only consider the method unknown if it is an ognl MethodFailedException and the cause is a java.lang.NoSuchMethodException -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4480) DefaultActionInvocation.invokeAction calls unknownHandlerManager.handleUnknownMethod for any OgnlException
[ https://issues.apache.org/jira/browse/WW-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371351#comment-14371351 ] Jasper Rosenberg commented on WW-4480: -- will do, thanks DefaultActionInvocation.invokeAction calls unknownHandlerManager.handleUnknownMethod for any OgnlException -- Key: WW-4480 URL: https://issues.apache.org/jira/browse/WW-4480 Project: Struts 2 Issue Type: Bug Components: Core Actions Affects Versions: 2.3.20 Reporter: Jasper Rosenberg Priority: Minor Fix For: 2.3.x In our environment we are allowing method invocation exceptions in ognl to propagate. (This is so we can fail fast if someone tries to write code that invokes a static method) However, DefaultActionInvocation.invokeAction() does not distinguish between an OgnlException because of the method missing, and an OgnlException because the method threw an exception during execution. It calls handleUnknownMethod in both cases. Instead of just checking for OgnlException it should only consider the method unknown if it is an ognl MethodFailedException and the cause is a java.lang.NoSuchMethodException -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (WW-4451) OgnlRuntime not threadsafe
[ https://issues.apache.org/jira/browse/WW-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasper Rosenberg resolved WW-4451. -- Resolution: Fixed Moved to 2.5 OgnlRuntime not threadsafe -- Key: WW-4451 URL: https://issues.apache.org/jira/browse/WW-4451 Project: Struts 2 Issue Type: Bug Components: Value Stack Affects Versions: 2.3.20 Reporter: Jasper Rosenberg Assignee: Lukasz Lenart Priority: Critical Fix For: 2.5 Access to _methodAccessCache and _methodPermCache is not thread-safe. Ognl 4.0 actually addresses this by using a ConcurrentHashMap. Twice in the last couple of years we have had a server die shortly after startup because of this issue. Simplest fix is to just replace the uses of IntHashMap with ConcurrentHashMapInteger, Boolean (assuming ognl doesn't have to support java 4) Alternatively, you could probably get away with the same solution used to protect uses of cacheSetMethod (though it isn't strictly correct since someone could still be calling get on cacheSetMethod in parallel to a put and get the wrong result). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WW-4451) OgnlRuntime not threadsafe
[ https://issues.apache.org/jira/browse/WW-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasper Rosenberg updated WW-4451: - Fix Version/s: (was: 2.3.22) 2.5 OgnlRuntime not threadsafe -- Key: WW-4451 URL: https://issues.apache.org/jira/browse/WW-4451 Project: Struts 2 Issue Type: Bug Components: Value Stack Affects Versions: 2.3.20 Reporter: Jasper Rosenberg Assignee: Lukasz Lenart Priority: Critical Fix For: 2.5 Access to _methodAccessCache and _methodPermCache is not thread-safe. Ognl 4.0 actually addresses this by using a ConcurrentHashMap. Twice in the last couple of years we have had a server die shortly after startup because of this issue. Simplest fix is to just replace the uses of IntHashMap with ConcurrentHashMapInteger, Boolean (assuming ognl doesn't have to support java 4) Alternatively, you could probably get away with the same solution used to protect uses of cacheSetMethod (though it isn't strictly correct since someone could still be calling get on cacheSetMethod in parallel to a put and get the wrong result). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (WW-4451) OgnlRuntime not threadsafe
[ https://issues.apache.org/jira/browse/WW-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasper Rosenberg reopened WW-4451: -- This may be resolved, but presumably not for 2.3.22 which still references ognl 3.0.6 right? (as it should due to regression issues) OgnlRuntime not threadsafe -- Key: WW-4451 URL: https://issues.apache.org/jira/browse/WW-4451 Project: Struts 2 Issue Type: Bug Components: Value Stack Affects Versions: 2.3.20 Reporter: Jasper Rosenberg Assignee: Lukasz Lenart Priority: Critical Fix For: 2.5 Access to _methodAccessCache and _methodPermCache is not thread-safe. Ognl 4.0 actually addresses this by using a ConcurrentHashMap. Twice in the last couple of years we have had a server die shortly after startup because of this issue. Simplest fix is to just replace the uses of IntHashMap with ConcurrentHashMapInteger, Boolean (assuming ognl doesn't have to support java 4) Alternatively, you could probably get away with the same solution used to protect uses of cacheSetMethod (though it isn't strictly correct since someone could still be calling get on cacheSetMethod in parallel to a put and get the wrong result). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (WW-4480) DefaultActionInvocation.invokeAction calls unknownHandlerManager.handleUnknownMethod for any OgnlException
[ https://issues.apache.org/jira/browse/WW-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasper Rosenberg closed WW-4480. Resolution: Duplicate Fix Version/s: (was: 2.3.x) 2.3.22 Yup, that was it. DefaultActionInvocation.invokeAction calls unknownHandlerManager.handleUnknownMethod for any OgnlException -- Key: WW-4480 URL: https://issues.apache.org/jira/browse/WW-4480 Project: Struts 2 Issue Type: Bug Components: Core Actions Affects Versions: 2.3.20 Reporter: Jasper Rosenberg Priority: Minor Fix For: 2.3.22 In our environment we are allowing method invocation exceptions in ognl to propagate. (This is so we can fail fast if someone tries to write code that invokes a static method) However, DefaultActionInvocation.invokeAction() does not distinguish between an OgnlException because of the method missing, and an OgnlException because the method threw an exception during execution. It calls handleUnknownMethod in both cases. Instead of just checking for OgnlException it should only consider the method unknown if it is an ognl MethodFailedException and the cause is a java.lang.NoSuchMethodException -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WW-4481) Deprecated warning gives no context
Jasper Rosenberg created WW-4481: Summary: Deprecated warning gives no context Key: WW-4481 URL: https://issues.apache.org/jira/browse/WW-4481 Project: Struts 2 Issue Type: Bug Components: Value Stack Affects Versions: 2.3.22 Reporter: Jasper Rosenberg Priority: Critical I released 2.3.22 and immediately had my log files fill up with this warning: WARN [SecurityMemberAccess] Support for accessing static methods is deprecated! Please refactor your application! I was surprised because I thought I had actually removed all static references, but I can't find what I missed because this warning has no context. Can you please add the information about the expression being evaluated so I can track down the usage? Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4479) Ognl can't access static field on enum
[ https://issues.apache.org/jira/browse/WW-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14370284#comment-14370284 ] Jasper Rosenberg commented on WW-4479: -- Yes, that stackoverflow post describes the bug. It's a relatively easy to fix in OgnlRuntime.getStaticField() though. Ognl can't access static field on enum -- Key: WW-4479 URL: https://issues.apache.org/jira/browse/WW-4479 Project: Struts 2 Issue Type: Bug Components: Expression Language Affects Versions: 2.3.20 Reporter: Jasper Rosenberg Labels: ognl Fix For: 2.5 You can use an ognl expression to access a static field or an enum field, but you can't access a static field on an enum. @com.myco.MyEnum@MY_STATIC_FIELD blows up with: Caused by: java.lang.IllegalArgumentException: No enum constant com.myco.MyEnum.MY_STATIC_FIELD OgnlRuntime.getStaticField() needs to check for both enum field name and static field name for enums. This is particularly annoying now with ognl static method invocation deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (WW-4479) Ognl can't access static field on enum
[ https://issues.apache.org/jira/browse/WW-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14370284#comment-14370284 ] Jasper Rosenberg edited comment on WW-4479 at 3/19/15 10:55 PM: Yes, that stackoverflow post describes the same bug. It's a relatively easy to fix in OgnlRuntime.getStaticField() though. was (Author: perfnorm): Yes, that stackoverflow post describes the bug. It's a relatively easy to fix in OgnlRuntime.getStaticField() though. Ognl can't access static field on enum -- Key: WW-4479 URL: https://issues.apache.org/jira/browse/WW-4479 Project: Struts 2 Issue Type: Bug Components: Expression Language Affects Versions: 2.3.20 Reporter: Jasper Rosenberg Labels: ognl Fix For: 2.5 You can use an ognl expression to access a static field or an enum field, but you can't access a static field on an enum. @com.myco.MyEnum@MY_STATIC_FIELD blows up with: Caused by: java.lang.IllegalArgumentException: No enum constant com.myco.MyEnum.MY_STATIC_FIELD OgnlRuntime.getStaticField() needs to check for both enum field name and static field name for enums. This is particularly annoying now with ognl static method invocation deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WW-4479) Ognl can't access static field on enum
Jasper Rosenberg created WW-4479: Summary: Ognl can't access static field on enum Key: WW-4479 URL: https://issues.apache.org/jira/browse/WW-4479 Project: Struts 2 Issue Type: Bug Components: Expression Language Affects Versions: 2.3.20 Reporter: Jasper Rosenberg You can use an ognl expression to access a static field or an enum field, but you can't access a static field on an enum. @com.myco.MyEnum@MY_STATIC_FIELD blows up with: Caused by: java.lang.IllegalArgumentException: No enum constant com.myco.MyEnum.MY_STATIC_FIELD OgnlRuntime.getStaticField() needs to check for both enum field name and static field name for enums. This is particularly annoying now with ognl static method invocation deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WW-4478) Can't install own ValidatorFileParser
Jasper Rosenberg created WW-4478: Summary: Can't install own ValidatorFileParser Key: WW-4478 URL: https://issues.apache.org/jira/browse/WW-4478 Project: Struts 2 Issue Type: Improvement Components: XML Validators Affects Versions: 2.3.20 Reporter: Jasper Rosenberg Priority: Minor I'd like to install my own implementation of com.opensymphony.xwork2.validator.ValidatorFileParser, but I can't w/o overwriting the whole default struts xml because it uses default as the name, and there is no property with which to set it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WW-4475) CarGurusValueStackFactory.setContainer() has unused local variable
Jasper Rosenberg created WW-4475:
Summary: CarGurusValueStackFactory.setContainer() has unused local
variable
Key: WW-4475
URL: https://issues.apache.org/jira/browse/WW-4475
Project: Struts 2
Issue Type: Bug
Components: Core Actions
Reporter: Jasper Rosenberg
Priority: Minor
Not sure of the intent, but this code appears to do nothing...
{code:java}
if (Map.class.isAssignableFrom(cls)) {
PropertyAccessor acc = container.getInstance(PropertyAccessor.class, name);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WW-4476) URLUtil is deprecated but doesn't suggest a replacement
Jasper Rosenberg created WW-4476: Summary: URLUtil is deprecated but doesn't suggest a replacement Key: WW-4476 URL: https://issues.apache.org/jira/browse/WW-4476 Project: Struts 2 Issue Type: Bug Components: Documentation Reporter: Jasper Rosenberg Priority: Trivial URLUtil.verifyUrl() doesn't suggest a replacement -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WW-4462) Regression bug in ognl for is... property getters
Jasper Rosenberg created WW-4462:
Summary: Regression bug in ognl for is... property getters
Key: WW-4462
URL: https://issues.apache.org/jira/browse/WW-4462
Project: Struts 2
Issue Type: Bug
Components: Core Actions
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Critical
We have a lot of getters on our actions that look like:
public boolean getIsTruck() {
return isTruck;
}
That lets us write ftl that looks like:
#if isTruck.../#if
However, this support was broken in a recent ognl release, I believe by this
patch:
https://github.com/jkuhnert/ognl/commit/6fb948c8a4528546e6e24750f09a89b6a730e17a
I don't see any reason why this pattern shouldn't be supported, so I'm assuming
it is a bug.
This is also keeping us from being able to upgrade to the latest ognl which has
some critical fixes we were really hoping to take advantage of.
Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WW-4463) Support propagating ognl errors other than NoSuchPropertyException
Jasper Rosenberg created WW-4463:
Summary: Support propagating ognl errors other than
NoSuchPropertyException
Key: WW-4463
URL: https://issues.apache.org/jira/browse/WW-4463
Project: Struts 2
Issue Type: Improvement
Components: Core Actions
Affects Versions: 2.3.20
Reporter: Jasper Rosenberg
Priority: Minor
So, if you have a getter on an action that does some real work (say lazy load a
list of cars from the database), and therefore might fail, it would be nice to
have the option to have that propagate the exception, rather than be
interpreted as if the property was not defined.
The place that looks like this should be done is OgnlValueStack.setValue(). It
takes throwExceptionOnFailure, but that is all or nothing. That ends up
including XWorkExceptions with a root issue of ognl NoSuchPropertyException.
These are frequent and not something we care about, at least in our code base.
What I'd like to do is have some kind of parameterization that would let me
turn on error propagation for not ognl property missing error. I did this
locally, but it had to be super hacky because OgnlValueStack.setValue() is
private. I basically installed my own ValueStackFactory that returned a copy
of OgnlValueStack with the function changed to be like:
{code:java}
/**
* @see com.opensymphony.xwork2.util.ValueStack#findValue(java.lang.String)
*/
public Object findValue(String expr, boolean throwExceptionOnFailure) {
try {
setupExceptionOnFailure(throwExceptionOnFailure);
return tryFindValueWhenExpressionIsNotNull(expr);
} catch (OgnlException e) {
return handleOgnlException(expr, throwExceptionOnFailure, e);
} catch (XWorkException e) {
Throwable cause = e.getCause();
if (cause instanceof NoSuchPropertyException) {
return handleOtherException(expr, throwExceptionOnFailure, e);
}
return handleOtherException(expr, true, e);
} catch (Exception e) {
return handleOtherException(expr, throwExceptionOnFailure, e);
} finally {
ReflectionContextState.clear(context);
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4451) OgnlRuntime not threadsafe
[ https://issues.apache.org/jira/browse/WW-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14300241#comment-14300241 ] Jasper Rosenberg commented on WW-4451: -- Got it. Thanks for taking care of this so quickly! OgnlRuntime not threadsafe -- Key: WW-4451 URL: https://issues.apache.org/jira/browse/WW-4451 Project: Struts 2 Issue Type: Bug Components: Value Stack Affects Versions: 2.3.21 Reporter: Jasper Rosenberg Assignee: Lukasz Lenart Priority: Critical Fix For: 2.3.22 Access to _methodAccessCache and _methodPermCache is not thread-safe. Ognl 4.0 actually addresses this by using a ConcurrentHashMap. Twice in the last couple of years we have had a server die shortly after startup because of this issue. Simplest fix is to just replace the uses of IntHashMap with ConcurrentHashMapInteger, Boolean (assuming ognl doesn't have to support java 4) Alternatively, you could probably get away with the same solution used to protect uses of cacheSetMethod (though it isn't strictly correct since someone could still be calling get on cacheSetMethod in parallel to a put and get the wrong result). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4451) OgnlRuntime not threadsafe
[ https://issues.apache.org/jira/browse/WW-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287680#comment-14287680 ] Jasper Rosenberg commented on WW-4451: -- Yeah, I noticed that you have done a couple of intermediate ognl releases. I think we are actually already referencing a newer ognl than the struts default. I'm a bit worried about running into unexpected issues with the 3.0.8 release though since it changed how ognl interpreted property names... OgnlRuntime not threadsafe -- Key: WW-4451 URL: https://issues.apache.org/jira/browse/WW-4451 Project: Struts 2 Issue Type: Bug Components: Value Stack Affects Versions: 2.3.21 Reporter: Jasper Rosenberg Priority: Critical Fix For: 2.3.22 Access to _methodAccessCache and _methodPermCache is not thread-safe. Ognl 4.0 actually addresses this by using a ConcurrentHashMap. Twice in the last couple of years we have had a server die shortly after startup because of this issue. Simplest fix is to just replace the uses of IntHashMap with ConcurrentHashMapInteger, Boolean (assuming ognl doesn't have to support java 4) Alternatively, you could probably get away with the same solution used to protect uses of cacheSetMethod (though it isn't strictly correct since someone could still be calling get on cacheSetMethod in parallel to a put and get the wrong result). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WW-4451) OgnlRuntime not threadsafe
Jasper Rosenberg created WW-4451: Summary: OgnlRuntime not threadsafe Key: WW-4451 URL: https://issues.apache.org/jira/browse/WW-4451 Project: Struts 2 Issue Type: Bug Components: Value Stack Affects Versions: 2.3.21 Reporter: Jasper Rosenberg Priority: Critical Access to _methodAccessCache and _methodPermCache is not thread-safe. Ognl 4.0 actually addresses this by using a ConcurrentHashMap. Twice in the last couple of years we have had a server die shortly after startup because of this issue. Simplest fix is to just replace the uses of IntHashMap with ConcurrentHashMapInteger, Boolean (assuming ognl doesn't have to support java 4) Alternatively, you could probably get away with the same solution used to protect uses of cacheSetMethod (though it isn't strictly correct since someone could still be calling get on cacheSetMethod in parallel to a put and get the wrong result). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4160) Construct UnknownHandler using Spring
[
https://issues.apache.org/jira/browse/WW-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14068097#comment-14068097
]
Jasper Rosenberg commented on WW-4160:
--
Seems like a great solution!
Construct UnknownHandler using Spring
-
Key: WW-4160
URL: https://issues.apache.org/jira/browse/WW-4160
Project: Struts 2
Issue Type: Improvement
Components: Plugin - Spring, XML Configuration
Affects Versions: 2.3.15.1
Reporter: Jasper Rosenberg
Assignee: Lukasz Lenart
Priority: Minor
Fix For: 2.3.18
I have a custom unknown handler in my struts2 definition (to return a 404 in
production if the method is not found). I would like to have the handler
constructed by Spring instead of the xwork container though so that I can
have some other logging/debugging resources injected.
{code}
bean type=com.opensymphony.xwork2.UnknownHandler
name=pageNotFoundUnknownHandler
class=com.mycompany.PageNotFoundUnknownHandler/
unknown-handler-stack
unknown-handler-ref name=pageNotFoundUnknownHandler /
/unknown-handler-stack
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (WW-4150) Support attributes with hyphens in tag dynamic attributes
[
https://issues.apache.org/jira/browse/WW-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059779#comment-14059779
]
Jasper Rosenberg commented on WW-4150:
--
Yes, that looks good.
Support attributes with hyphens in tag dynamic attributes
-
Key: WW-4150
URL: https://issues.apache.org/jira/browse/WW-4150
Project: Struts 2
Issue Type: Improvement
Components: Other
Affects Versions: 2.3.15.1
Reporter: Jasper Rosenberg
Priority: Minor
Fix For: 2.3.18
A lot of CSS/JS frameworks look for attributes on html elements that include
a hyphen to do their magic (JQuery Mobile, Bootstrap, etc).
For example, in my JQuery Mobile app, I'd like to be able to say:
{code}
@s.form ... data-ajax=false
/@s.form
{code}
Unfortunately, this doesn't work because Freemarker doesn't allow hyphens in
macro parameter names. I entered an enhancement request for this here:
https://sourceforge.net/p/freemarker/bugs/395/
I'm not sure when or if that might be fixed, so perhaps a work around would
be to allow explicit dynamic attributes through some kind of parameter
convention.
{code}
@s.form ...
@s.param name=dyn:data-ajax value=false/
/@s.form
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (WW-4170) Allow String arrays/iterables to be passed as params to redirectAction result
[
https://issues.apache.org/jira/browse/WW-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14055740#comment-14055740
]
Jasper Rosenberg commented on WW-4170:
--
Looks like it should work, thanks!
Allow String arrays/iterables to be passed as params to redirectAction result
-
Key: WW-4170
URL: https://issues.apache.org/jira/browse/WW-4170
Project: Struts 2
Issue Type: Improvement
Components: Other
Affects Versions: 2.3.15.1
Reporter: Jasper Rosenberg
Labels: result
Fix For: 2.3.18
It would be really nice to be able to have a result like:
{code:xml}
result type=redirectAction
param name=actionNamedoit/param
param name=actionMessages${actionMessages}/param
/result
{code}
Where actionMessages is the result of getActionMessages() from a
ValidationAware action, and has more than one message.
And have that generate a url like:
http://myco.com/doit.action?actionMessages=Message+1actionMessages=Message+2
Rather than convert the result into the toString of the collection which then
can't be interpreted by struts on the other end as a collection.
Looking at ServletRedirectResult.doExecute(), it does use
urlHelper.buildParametersString() which is array/iterable aware, so the trick
would be to allow the parsing of the parameter value to be a String[] or
IterableString (and have the ParsedValueEvaluator run against the contents).
We'd probably only want to support this functionality for the
ServletActionRedirectResult even though it would have to be implemented at
the ServletRedirectResult layer.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (WW-4329) Support ConfigurationManagerListener
Jasper Rosenberg created WW-4329: Summary: Support ConfigurationManagerListener Key: WW-4329 URL: https://issues.apache.org/jira/browse/WW-4329 Project: Struts 2 Issue Type: Improvement Components: Core Actions Reporter: Jasper Rosenberg Priority: Minor I wanted to run some validation checks on the actions after they were loaded. I could do it at startup by creating a DispatcherListener. However, in development, if the Configuration reloads in devMode, I have no way to know that and rerun my validation. It would be great to just mimic the DispatcherListener pattern for the ConfigurationManager so one could register ConfigurationManagerListeners for when the configuration is loaded/reload. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (WW-4149) No easy way to have an empty interceptor stack if have default stack
[ https://issues.apache.org/jira/browse/WW-4149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937754#comment-13937754 ] Jasper Rosenberg commented on WW-4149: -- I actually use an empty stack a ton. Pretty much anytime we have a view that doesn't look at query parameters (but is still dynamic because the user may be logged in, etc), I use an empty stack since it is just overhead at that point. No easy way to have an empty interceptor stack if have default stack Key: WW-4149 URL: https://issues.apache.org/jira/browse/WW-4149 Project: Struts 2 Issue Type: Improvement Components: Core Interceptors Affects Versions: 2.3.15.1 Reporter: Jasper Rosenberg Fix For: 2.3.x If you have an action that you don't want to have any interceptors, if there is a defaultStack defined, you can't. My work around was to create an NoOpInterceptor that did nothing, and then declare interceptor stack that just included it to use. It used to be that you couldn't include an empty interceptor stack at all. That seems to not blow up now, but unfortunately it appears that it is treated as if it doesn't exist, and the defaultStack is used instead. I think a declared interceptor stack on an action should override the default, even if it is empty. Could then also provide an emptyStack interceptor in struts-default.xml that people could use when they wanted this behavior. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (WW-4149) No easy way to have an empty interceptor stack if have default stack
[ https://issues.apache.org/jira/browse/WW-4149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937807#comment-13937807 ] Jasper Rosenberg commented on WW-4149: -- Makes sense, there is also an easy workaround. No easy way to have an empty interceptor stack if have default stack Key: WW-4149 URL: https://issues.apache.org/jira/browse/WW-4149 Project: Struts 2 Issue Type: Improvement Components: Core Interceptors Affects Versions: 2.3.15.1 Reporter: Jasper Rosenberg Fix For: 2.5 If you have an action that you don't want to have any interceptors, if there is a defaultStack defined, you can't. My work around was to create an NoOpInterceptor that did nothing, and then declare interceptor stack that just included it to use. It used to be that you couldn't include an empty interceptor stack at all. That seems to not blow up now, but unfortunately it appears that it is treated as if it doesn't exist, and the defaultStack is used instead. I think a declared interceptor stack on an action should override the default, even if it is empty. Could then also provide an emptyStack interceptor in struts-default.xml that people could use when they wanted this behavior. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (WW-4288) staticParams interceptor overwrites params conversion errors
[
https://issues.apache.org/jira/browse/WW-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897818#comment-13897818
]
Jasper Rosenberg commented on WW-4288:
--
A few more thoughts:
1. This could be fixed pretty easily I believe by simply changing that line in
StaticParametersInterceptor (and the same in ParametersInterceptor) to merge
the values of ActionContext.CONVERSION_ERRORS rather than overwrite them.
(Either that or when creating newStack from stack, make sure the conversion
errors are copied)
2. A workaround for the bug might be to include the conversionError interceptor
after each params interceptor (I did a different temp hack which was to add a
new interceptor after each params interceptor that saved and restored the value
in ActionContext.CONVERSION_ERRORS)
3. It looks like this was broken on 2012-02-22 by issue WW-3760
4. I think an argument can be made that this is actually a security issue. If
you were relying on type conversion errors from preventing malformed requests
getting through, and had both parameter interceptors on your stack, it stopped
working with the release of WW-3760.
staticParams interceptor overwrites params conversion errors
Key: WW-4288
URL: https://issues.apache.org/jira/browse/WW-4288
Project: Struts 2
Issue Type: Bug
Components: Core Interceptors
Affects Versions: 2.3.15.3
Reporter: Jasper Rosenberg
Fix For: 2.3.x
Have a stack like:
...
interceptor-ref name=params
interceptor-ref name=staticParams/
...
interceptor-ref name=conversionError/
If have type conversion errors in params, they aren't seen by the
conversionError interceptor.
It looks like this in StaticParametersInterceptor:
{code:java}
if (clearableStack (stack.getContext() != null)
(newStack.getContext() != null))
stack.getContext().put(ActionContext.CONVERSION_ERRORS,
newStack.getContext().get(ActionContext.CONVERSION_ERRORS));
{code}
ends up just overwriting the old value of ActionContext.CONVERSION_ERRORS
rather than merging.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (WW-4288) staticParams interceptor overwrites params conversion errors
[
https://issues.apache.org/jira/browse/WW-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897854#comment-13897854
]
Jasper Rosenberg commented on WW-4288:
--
Whoops, totally wrong :) I was trying to find the version where that change
went in and missed it. (Gotta get Git setup locally so I don't have to use the
web source viewer). I now see that it has been like this since xwork was
brought into the struts2 project. It's weird though because I could have sworn
it used to work...
staticParams interceptor overwrites params conversion errors
Key: WW-4288
URL: https://issues.apache.org/jira/browse/WW-4288
Project: Struts 2
Issue Type: Bug
Components: Core Interceptors
Affects Versions: 2.3.15.3
Reporter: Jasper Rosenberg
Fix For: 2.3.x
Have a stack like:
...
interceptor-ref name=params
interceptor-ref name=staticParams/
...
interceptor-ref name=conversionError/
If have type conversion errors in params, they aren't seen by the
conversionError interceptor.
It looks like this in StaticParametersInterceptor:
{code:java}
if (clearableStack (stack.getContext() != null)
(newStack.getContext() != null))
stack.getContext().put(ActionContext.CONVERSION_ERRORS,
newStack.getContext().get(ActionContext.CONVERSION_ERRORS));
{code}
ends up just overwriting the old value of ActionContext.CONVERSION_ERRORS
rather than merging.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (WW-4289) SpringObjectFactory does not obey InitializingBean interface
Jasper Rosenberg created WW-4289: Summary: SpringObjectFactory does not obey InitializingBean interface Key: WW-4289 URL: https://issues.apache.org/jira/browse/WW-4289 Project: Struts 2 Issue Type: Bug Components: Plugin - Spring Reporter: Jasper Rosenberg Priority: Minor SpringObjectFactory has the comment: // We don't need to call the init-method since one won't be registered. Unfortunately, that isn't true since the bean may implement the Spring interface: InitializingBean Instead of the comment, it should call: initializeBean(bean, bean.getClass().getName()); -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (WW-4290) DefaultTypeConverter primitiveDefaults should be static
Jasper Rosenberg created WW-4290: Summary: DefaultTypeConverter primitiveDefaults should be static Key: WW-4290 URL: https://issues.apache.org/jira/browse/WW-4290 Project: Struts 2 Issue Type: Improvement Components: Other Reporter: Jasper Rosenberg Priority: Minor Each type converter which extends DefaultTypeConverter ends up creating its own copy of the private final unmodifable map primitiveDefaults. It should just be static and be initialized statically. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (WW-4291) Can't use Spring bean name for type convertor
Jasper Rosenberg created WW-4291:
Summary: Can't use Spring bean name for type convertor
Key: WW-4291
URL: https://issues.apache.org/jira/browse/WW-4291
Project: Struts 2
Issue Type: Improvement
Components: Plugin - Spring
Reporter: Jasper Rosenberg
Priority: Minor
If in your xwork.conversion.properties file you try to use a Spring bean name
instead of a class name, it blows up.
This is because DefaultConfiguration.createBootstrapContainer() ends up using
DefaultTypeConverterCreator which has the generic ObjectFactory at that point
because it happens before the struts.properties file is ever loaded (where in
my case the SpringObjectFactory is defined.)
{noformat}
10:20:06,910 ERROR [DefaultConversionPropertiesProcessor] Conversion
registration error
java.lang.ClassNotFoundException: entityObjectTypeConvertor
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1680)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526)
at
com.opensymphony.xwork2.util.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:152)
at
com.opensymphony.xwork2.ObjectFactory.getClassInstance(ObjectFactory.java:108)
at
com.opensymphony.xwork2.ObjectFactory.buildBean(ObjectFactory.java:161)
at
com.opensymphony.xwork2.ObjectFactory.buildBean(ObjectFactory.java:151)
at
com.opensymphony.xwork2.conversion.impl.DefaultTypeConverterCreator.createTypeConverter(DefaultTypeConverterCreator.java:23)
at
com.opensymphony.xwork2.conversion.impl.DefaultConversionPropertiesProcessor.loadConversionProperties(DefaultConversionPropertiesProcessor.java:64)
at
com.opensymphony.xwork2.conversion.impl.DefaultConversionPropertiesProcessor.process(DefaultConversionPropertiesProcessor.java:40)
at
com.opensymphony.xwork2.conversion.impl.XWorkConverter.setConversionPropertiesProcessor(XWorkConverter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.opensymphony.xwork2.inject.ContainerImpl$MethodInjector.inject(ContainerImpl.java:299)
at
com.opensymphony.xwork2.inject.ContainerImpl$ConstructorInjector.construct(ContainerImpl.java:438)
at
com.opensymphony.xwork2.inject.ContainerBuilder$5.create(ContainerBuilder.java:207)
...
at
com.opensymphony.xwork2.inject.ContainerBuilder$7.call(ContainerBuilder.java:484)
at
com.opensymphony.xwork2.inject.ContainerImpl.callInContext(ContainerImpl.java:584)
at
com.opensymphony.xwork2.inject.ContainerBuilder.create(ContainerBuilder.java:484)
at
com.opensymphony.xwork2.config.impl.DefaultConfiguration.createBootstrapContainer(DefaultConfiguration.java:324)
at
com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:221)
at
com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:67)
at
org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:446)
at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:490)
at
org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher(InitOperations.java:74)
at
org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init(StrutsPrepareAndExecuteFilter.java:57)
at
org.springframework.web.filter.DelegatingFilterProxy.initDelegate(DelegatingFilterProxy.java:325)
at
org.springframework.web.filter.DelegatingFilterProxy.initFilterBean(DelegatingFilterProxy.java:235)
at
org.springframework.web.filter.GenericFilterBean.init(GenericFilterBean.java:194)
at
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:295)
at
org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:422)
at
org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:115)
at
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4072)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4726)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:943)
at
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:778)
at
[jira] [Created] (WW-4288) staticParams interceptor overwrites params conversion errors
Jasper Rosenberg created WW-4288:
Summary: staticParams interceptor overwrites params conversion
errors
Key: WW-4288
URL: https://issues.apache.org/jira/browse/WW-4288
Project: Struts 2
Issue Type: Bug
Components: Core Interceptors
Affects Versions: 2.3.15.3
Reporter: Jasper Rosenberg
Have a stack like:
...
interceptor-ref name=params
interceptor-ref name=staticParams/
...
interceptor-ref name=conversionError/
If have type conversion errors in params, they aren't seen by the
conversionError interceptor.
It looks like this in StaticParametersInterceptor:
{code:java}
if (clearableStack (stack.getContext() != null)
(newStack.getContext() != null))
stack.getContext().put(ActionContext.CONVERSION_ERRORS,
newStack.getContext().get(ActionContext.CONVERSION_ERRORS));
{code}
ends up just overwriting the old value of ActionContext.CONVERSION_ERRORS
rather than merging.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (WW-4145) file.ftl in xhtml theme directly references xhtml controlfooter.ftl
[
https://issues.apache.org/jira/browse/WW-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13807055#comment-13807055
]
Jasper Rosenberg commented on WW-4145:
--
Looks great, can't wait for the next release!
file.ftl in xhtml theme directly references xhtml controlfooter.ftl
---
Key: WW-4145
URL: https://issues.apache.org/jira/browse/WW-4145
Project: Struts 2
Issue Type: Bug
Components: Other
Affects Versions: 2.3.15.1
Reporter: Jasper Rosenberg
Assignee: Lukasz Lenart
Labels: freemarker, tags, xhtml
Fix For: 2.3.16
Attachments: ThemeExpansion-Alt.patch, ThemeExpansion.patch
Should use $\{parameters.theme} instead so can be used in theme extension.
{code}
#include /${parameters.templateDir}/${parameters.theme}/controlheader.ftl
/
#include /${parameters.templateDir}/simple/file.ftl /
#include /${parameters.templateDir}/${parameters.theme}/controlfooter.ftl
/
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (WW-4145) file.ftl in xhtml theme directly references xhtml controlfooter.ftl
[
https://issues.apache.org/jira/browse/WW-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806495#comment-13806495
]
Jasper Rosenberg commented on WW-4145:
--
Maybe name it parameters.expandedTheme as expandTheme sounds like a
command? (or parameters.inheritingTheme perhaps?) Otherwise, sounds good to
me!
file.ftl in xhtml theme directly references xhtml controlfooter.ftl
---
Key: WW-4145
URL: https://issues.apache.org/jira/browse/WW-4145
Project: Struts 2
Issue Type: Bug
Components: Other
Affects Versions: 2.3.15.1
Reporter: Jasper Rosenberg
Assignee: Lukasz Lenart
Labels: freemarker, tags, xhtml
Fix For: 2.3.16
Attachments: ThemeExpansion-Alt.patch, ThemeExpansion.patch
Should use $\{parameters.theme} instead so can be used in theme extension.
{code}
#include /${parameters.templateDir}/${parameters.theme}/controlheader.ftl
/
#include /${parameters.templateDir}/simple/file.ftl /
#include /${parameters.templateDir}/${parameters.theme}/controlfooter.ftl
/
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (WW-4145) file.ftl in xhtml theme directly references xhtml controlfooter.ftl
[
https://issues.apache.org/jira/browse/WW-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806177#comment-13806177
]
Jasper Rosenberg commented on WW-4145:
--
Excellent, glad you found a solution since I wasn't going to be able to look at
it until Monday. Thanks!
file.ftl in xhtml theme directly references xhtml controlfooter.ftl
---
Key: WW-4145
URL: https://issues.apache.org/jira/browse/WW-4145
Project: Struts 2
Issue Type: Bug
Components: Other
Affects Versions: 2.3.15.1
Reporter: Jasper Rosenberg
Assignee: Lukasz Lenart
Labels: freemarker, tags, xhtml
Fix For: 2.3.16
Attachments: ThemeExpansion-Alt.patch, ThemeExpansion.patch
Should use $\{parameters.theme} instead so can be used in theme extension.
{code}
#include /${parameters.templateDir}/${parameters.theme}/controlheader.ftl
/
#include /${parameters.templateDir}/simple/file.ftl /
#include /${parameters.templateDir}/${parameters.theme}/controlfooter.ftl
/
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (WW-4203) Allow disabling xwork creating null objects on a property level
Jasper Rosenberg created WW-4203: Summary: Allow disabling xwork creating null objects on a property level Key: WW-4203 URL: https://issues.apache.org/jira/browse/WW-4203 Project: Struts 2 Issue Type: Improvement Components: Core Interceptors Affects Versions: 2.3.15.2, 2.3.15.1 Reporter: Jasper Rosenberg Priority: Minor Currently, the ParametersInterceptor sets: ReflectionContextState.setCreatingNullObjects(contextMap, true) This is great for parameters like person.name=Phil since it will create the Person object for you and then set the name. However, sometimes you have a converter for a property that will set it as a whole, and you want to make sure that an empty object is never created. For example, person=6, where the Person is set by looking it up by id. Currently, if someone messed with the url and made it person[x]=6, XWork would end up creating an empty Person object. (Something along these lines happened to us and I was looking for a clean way to tell XWork to not allow it) Perhaps the TypeConversion annotation could be extended to support this as an additional flag. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WW-4183) xhtml theme field errors are always centered
Jasper Rosenberg created WW-4183: Summary: xhtml theme field errors are always centered Key: WW-4183 URL: https://issues.apache.org/jira/browse/WW-4183 Project: Struts 2 Issue Type: Improvement Affects Versions: 2.3.15.1 Reporter: Jasper Rosenberg Priority: Minor In xhtml/controlheader-core.ftl, the td that holds the error message is hard coded to align=center. That often looks pretty bad, particularly if labelposition is top, since that is left aligned. In a perfect world, I'd like to just remove the align=center, and let people use CSS to decide the position of the error (maybe copying over the wwerr style from the css_xhtml theme to be consistent and make it easier to match). If that is too big a regression change, an alternative is to enhance errorPosition to also support: top-left, top-center, bottom-left, bottom-center -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WW-4172) action: parameter prefix can be used to access url secured content
Jasper Rosenberg created WW-4172:
Summary: action: parameter prefix can be used to access url
secured content
Key: WW-4172
URL: https://issues.apache.org/jira/browse/WW-4172
Project: Struts 2
Issue Type: Bug
Components: Other
Affects Versions: 2.3.15.1
Environment: Spring Security
Reporter: Jasper Rosenberg
Priority: Blocker
Let's say you have the following mappings:
{code:xml}
package name=securityTest namespace=/securitytest extends=default
action name=secureAction
resultsecure.ftl/result
/action
action name=insecureAction
resultinsecure.ftl/result
/action
/package
{code}
Then suppose you are using url pattern based security such as with Spring
Security, and require login to view secureAction.action:
{code:xml}
http use-expressions=true
intercept-url pattern=/securitytest/insecureAction.action
access=permitAll/
intercept-url pattern=/securitytest/secureAction.action
access=isAuthenticated/
form-login /
/http
{code}
Now:
1. http://localhost/securitytest/insecureAction.action
Shows the insecure content
2. http://localhost/securitytest/secureAction.action
Requires login before displaying secure content
3. http://localhost/securitytest/insecureAction.action?action:secureAction
Whoops, there's the secure content without login!
I believe this is only a problem if you are hosting the secure and insecure
actions in the same namespace.
Obviously, this is not directly a Struts2 issue, but I'm sure that many sites
are using url based security and Struts2 together. At the very least, it might
be good to provide an easy way to disable support for the action: parameter
prefix. For now I just extended the DefaultActionMapper, and overwrote the
value of prefixTrie to be empty.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WW-4172) deleteing
[ https://issues.apache.org/jira/browse/WW-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasper Rosenberg resolved WW-4172. -- Resolution: Not A Problem not an issue deleteing - Key: WW-4172 URL: https://issues.apache.org/jira/browse/WW-4172 Project: Struts 2 Issue Type: Bug Components: Other Affects Versions: 2.3.15.1 Environment: deleting Reporter: Jasper Rosenberg Priority: Blocker deleting -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WW-4172) deleteing
[
https://issues.apache.org/jira/browse/WW-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jasper Rosenberg updated WW-4172:
-
Description: deleting (was: Let's say you have the following mappings:
{code:xml}
package name=securityTest namespace=/securitytest extends=default
action name=secureAction
resultsecure.ftl/result
/action
action name=insecureAction
resultinsecure.ftl/result
/action
/package
{code}
Then suppose you are using url pattern based security such as with Spring
Security, and require login to view secureAction.action:
{code:xml}
http use-expressions=true
intercept-url pattern=/securitytest/insecureAction.action
access=permitAll/
intercept-url pattern=/securitytest/secureAction.action
access=isAuthenticated/
form-login /
/http
{code}
Now:
1. http://localhost/securitytest/insecureAction.action
Shows the insecure content
2. http://localhost/securitytest/secureAction.action
Requires login before displaying secure content
3. http://localhost/securitytest/insecureAction.action?action:secureAction
Whoops, there's the secure content without login!
I believe this is only a problem if you are hosting the secure and insecure
actions in the same namespace.
Obviously, this is not directly a Struts2 issue, but I'm sure that many sites
are using url based security and Struts2 together. At the very least, it might
be good to provide an easy way to disable support for the action: parameter
prefix. For now I just extended the DefaultActionMapper, and overwrote the
value of prefixTrie to be empty.
)
Environment: deleting (was: Spring Security)
Labels: (was: security)
Summary: deleteing (was: action: parameter prefix can be used to
access url secured content)
deleteing
-
Key: WW-4172
URL: https://issues.apache.org/jira/browse/WW-4172
Project: Struts 2
Issue Type: Bug
Components: Other
Affects Versions: 2.3.15.1
Environment: deleting
Reporter: Jasper Rosenberg
Priority: Blocker
deleting
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (WW-4172) deleteing
[ https://issues.apache.org/jira/browse/WW-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasper Rosenberg closed WW-4172. deleteing - Key: WW-4172 URL: https://issues.apache.org/jira/browse/WW-4172 Project: Struts 2 Issue Type: Bug Components: Other Affects Versions: 2.3.15.1 Environment: deleting Reporter: Jasper Rosenberg Priority: Blocker deleting -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WW-4169) Freemarker template expansion wrong if action includes slashes
Jasper Rosenberg created WW-4169: Summary: Freemarker template expansion wrong if action includes slashes Key: WW-4169 URL: https://issues.apache.org/jira/browse/WW-4169 Project: Struts 2 Issue Type: Bug Components: Other Affects Versions: 2.3.15.1 Reporter: Jasper Rosenberg Priority: Minor For relative freemarker template locations, FreemarkerResult uses the current URL to figure out the path. This is assumes that the action name doesn't include any / characters. If it does then part of the action name ends up in the template path. Instead, it should use the namespace directly to build the template path which removes any ambiguity. Please see the attached patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WW-4169) Freemarker template expansion wrong if action includes slashes
[ https://issues.apache.org/jira/browse/WW-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasper Rosenberg updated WW-4169: - Attachment: FreemarkerResult.java.patch Freemarker template expansion wrong if action includes slashes -- Key: WW-4169 URL: https://issues.apache.org/jira/browse/WW-4169 Project: Struts 2 Issue Type: Bug Components: Other Affects Versions: 2.3.15.1 Reporter: Jasper Rosenberg Priority: Minor Labels: freemarker, result Attachments: FreemarkerResult.java.patch For relative freemarker template locations, FreemarkerResult uses the current URL to figure out the path. This is assumes that the action name doesn't include any / characters. If it does then part of the action name ends up in the template path. Instead, it should use the namespace directly to build the template path which removes any ambiguity. Please see the attached patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WW-4169) Freemarker template expansion wrong if action includes slashes
[ https://issues.apache.org/jira/browse/WW-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasper Rosenberg updated WW-4169: - Attachment: (was: FreemarkerResult.java.patch) Freemarker template expansion wrong if action includes slashes -- Key: WW-4169 URL: https://issues.apache.org/jira/browse/WW-4169 Project: Struts 2 Issue Type: Bug Components: Other Affects Versions: 2.3.15.1 Reporter: Jasper Rosenberg Priority: Minor Labels: freemarker, result For relative freemarker template locations, FreemarkerResult uses the current URL to figure out the path. This is assumes that the action name doesn't include any / characters. If it does then part of the action name ends up in the template path. Instead, it should use the namespace directly to build the template path which removes any ambiguity. Please see the attached patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WW-4169) Freemarker template expansion wrong if action includes slashes
[ https://issues.apache.org/jira/browse/WW-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasper Rosenberg updated WW-4169: - Attachment: FreemarkerResult.java.patch Updated patch to use location rather than overwrite method parameter locationArg which can be confusing Freemarker template expansion wrong if action includes slashes -- Key: WW-4169 URL: https://issues.apache.org/jira/browse/WW-4169 Project: Struts 2 Issue Type: Bug Components: Other Affects Versions: 2.3.15.1 Reporter: Jasper Rosenberg Priority: Minor Labels: freemarker, result Attachments: FreemarkerResult.java.patch For relative freemarker template locations, FreemarkerResult uses the current URL to figure out the path. This is assumes that the action name doesn't include any / characters. If it does then part of the action name ends up in the template path. Instead, it should use the namespace directly to build the template path which removes any ambiguity. Please see the attached patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WW-4169) Freemarker template expansion wrong if action includes slashes
[ https://issues.apache.org/jira/browse/WW-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasper Rosenberg updated WW-4169: - Attachment: (was: FreemarkerResult.java.patch) Freemarker template expansion wrong if action includes slashes -- Key: WW-4169 URL: https://issues.apache.org/jira/browse/WW-4169 Project: Struts 2 Issue Type: Bug Components: Other Affects Versions: 2.3.15.1 Reporter: Jasper Rosenberg Priority: Minor Labels: freemarker, result Attachments: FreemarkerResult.java.patch For relative freemarker template locations, FreemarkerResult uses the current URL to figure out the path. This is assumes that the action name doesn't include any / characters. If it does then part of the action name ends up in the template path. Instead, it should use the namespace directly to build the template path which removes any ambiguity. Please see the attached patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WW-4169) Freemarker template expansion wrong if action includes slashes
[ https://issues.apache.org/jira/browse/WW-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasper Rosenberg updated WW-4169: - Attachment: FreemarkerResult.java.patch Realized someone might be relying on member variable location being original location, so use new local variable to be explicit. Last patch version, I swear! :) Freemarker template expansion wrong if action includes slashes -- Key: WW-4169 URL: https://issues.apache.org/jira/browse/WW-4169 Project: Struts 2 Issue Type: Bug Components: Other Affects Versions: 2.3.15.1 Reporter: Jasper Rosenberg Priority: Minor Labels: freemarker, result Attachments: FreemarkerResult.java.patch For relative freemarker template locations, FreemarkerResult uses the current URL to figure out the path. This is assumes that the action name doesn't include any / characters. If it does then part of the action name ends up in the template path. Instead, it should use the namespace directly to build the template path which removes any ambiguity. Please see the attached patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WW-4170) Allow String arrays/iterables to be passed as params to redirectAction result
Jasper Rosenberg created WW-4170:
Summary: Allow String arrays/iterables to be passed as params to
redirectAction result
Key: WW-4170
URL: https://issues.apache.org/jira/browse/WW-4170
Project: Struts 2
Issue Type: Improvement
Components: Other
Affects Versions: 2.3.15.1
Reporter: Jasper Rosenberg
It would be really nice to be able to have a result like:
{code:xml}
result type=redirectAction
param name=actionNamedoit/param
param name=actionMessages${actionMessages}/param
/result
{code}
Where actionMessages is the result of getActionMessages() from a
ValidationAware action, and has more than one message.
And have that generate a url like:
http://myco.com/doit.action?actionMessages=Message+1actionMessages=Message+2
Rather than convert the result into the toString of the collection which then
can't be interpreted by struts on the other end as a collection.
Looking at ServletRedirectResult.doExecute(), it does use
urlHelper.buildParametersString() which is array/iterable aware, so the trick
would be to allow the parsing of the parameter value to be a String[] or
IterableString (and have the ParsedValueEvaluator run against the contents).
We'd probably only want to support this functionality for the
ServletActionRedirectResult even though it would have to be implemented at the
ServletRedirectResult layer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WW-4145) file.ftl in xhtml theme directly references xhtml controlfooter.ftl
[
https://issues.apache.org/jira/browse/WW-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jasper Rosenberg updated WW-4145:
-
Attachment: ThemeExpansion-Alt.patch
Alternate patch that sticks the theme aware template loader into the loader
stack in the FreemarkerManager instead of the FreemarkerTemplateEngine.
file.ftl in xhtml theme directly references xhtml controlfooter.ftl
---
Key: WW-4145
URL: https://issues.apache.org/jira/browse/WW-4145
Project: Struts 2
Issue Type: Bug
Components: Other
Affects Versions: 2.3.15.1
Reporter: Jasper Rosenberg
Assignee: Lukasz Lenart
Labels: freemarker, tags, xhtml
Fix For: 2.3.16
Attachments: ThemeExpansion-Alt.patch, ThemeExpansion.patch
Should use $\{parameters.theme} instead so can be used in theme extension.
{code}
#include /${parameters.templateDir}/${parameters.theme}/controlheader.ftl
/
#include /${parameters.templateDir}/simple/file.ftl /
#include /${parameters.templateDir}/${parameters.theme}/controlfooter.ftl
/
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WW-4164) Improve support for multiple extensions
Jasper Rosenberg created WW-4164:
Summary: Improve support for multiple extensions
Key: WW-4164
URL: https://issues.apache.org/jira/browse/WW-4164
Project: Struts 2
Issue Type: Improvement
Components: XML Configuration
Affects Versions: 2.3.15.1
Reporter: Jasper Rosenberg
Currently if you support multiple extensions (eg.
struts.action.extension=action,html,,) there is no way to tell struts for a
particular action which extension you always want to use. This has two
downsides:
1. When struts has to generate an url, for example in the form tag, or the
redirectAction result type, there is no way to specify the extension to use,
so it ends up using the current invocation's extension if possible, or
otherwise the default, neither of which might be correct.
2. You can invoke the action with any of the supported extensions, creating
duplicate pages with no clear canonical version. (Bad for SEO as well)
What I propose is allowing the user to specify an optional specific extension
at the package and action level in the struts xml configuration like so:
{code:xml}
package name=test namespace=/ extends=default extension=action
action name=a1 extension=
resulta1.ftl/result
/action
action name=b1 extension=html
resultb1.ftl/result
/action
action name=c1
resultb1.ftl/result
/action
/package
{code}
1. When selecting an extension when building an URL for an action, it would
first see if there was an extension to use at the action level. If not it
would check the package level (including package inheritance). If still no
specific extension, it would behave as it currently does.
2. When mapping an incoming URL to an action, the reverse will also hold. If
the action or its package specify a specific extension, then the action can
only be matched if the URL has that extension.
So in the above example, the following urls would be expected to work:
1. /a1 (action level no extension)
2. /b1.html (action level html extension)
3. /c1.action (no action level extension, using package level action
extension)
However, an url like /b1.action will not match any actions because action
extension doesn't match the action's html extension.
This change would be 100% backwards because if you don't specify any extension
attributes on the package or action, it falls back to the current behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WW-4164) Improve support for multiple extensions
[
https://issues.apache.org/jira/browse/WW-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726439#comment-13726439
]
Jasper Rosenberg commented on WW-4164:
--
True, but at least the way it needs to be changed is backwards compatible with
all previous dtds (just adding optional attributes).
Improve support for multiple extensions
---
Key: WW-4164
URL: https://issues.apache.org/jira/browse/WW-4164
Project: Struts 2
Issue Type: Improvement
Components: XML Configuration
Affects Versions: 2.3.15.1
Reporter: Jasper Rosenberg
Fix For: 2.5
Currently if you support multiple extensions (eg.
struts.action.extension=action,html,,) there is no way to tell struts for a
particular action which extension you always want to use. This has two
downsides:
1. When struts has to generate an url, for example in the form tag, or the
redirectAction result type, there is no way to specify the extension to
use, so it ends up using the current invocation's extension if possible, or
otherwise the default, neither of which might be correct.
2. You can invoke the action with any of the supported extensions, creating
duplicate pages with no clear canonical version. (Bad for SEO as well)
What I propose is allowing the user to specify an optional specific extension
at the package and action level in the struts xml configuration like so:
{code:xml}
package name=test namespace=/ extends=default extension=action
action name=a1 extension=
resulta1.ftl/result
/action
action name=b1 extension=html
resultb1.ftl/result
/action
action name=c1
resultb1.ftl/result
/action
/package
{code}
1. When selecting an extension when building an URL for an action, it would
first see if there was an extension to use at the action level. If not it
would check the package level (including package inheritance). If still no
specific extension, it would behave as it currently does.
2. When mapping an incoming URL to an action, the reverse will also hold. If
the action or its package specify a specific extension, then the action can
only be matched if the URL has that extension.
So in the above example, the following urls would be expected to work:
1. /a1 (action level no extension)
2. /b1.html (action level html extension)
3. /c1.action (no action level extension, using package level action
extension)
However, an url like /b1.action will not match any actions because action
extension doesn't match the action's html extension.
This change would be 100% backwards because if you don't specify any
extension attributes on the package or action, it falls back to the current
behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WW-4165) Form attribute includeContext is being inserted as a dynamicAttribute
Jasper Rosenberg created WW-4165:
Summary: Form attribute includeContext is being inserted as a
dynamicAttribute
Key: WW-4165
URL: https://issues.apache.org/jira/browse/WW-4165
Project: Struts 2
Issue Type: Bug
Components: Other
Affects Versions: 2.3.15.1
Environment: Freemarker
Reporter: Jasper Rosenberg
If you use the includeContext attribute on the Form element, it shows up as
an attribute on the rendered html form. This is because
UIBean.getStandardAttributes() only includes String and list type attributes,
but includeContext is a boolean.
{code}
@s.form action=myAction includeContext=false
{code}
Can either fix by making includeContext a String (like validate is in Form), or
having UIBean.getStandardAttributes() correctly detect it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WW-4165) Form attribute includeContext is being inserted as a dynamicAttribute
[
https://issues.apache.org/jira/browse/WW-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726774#comment-13726774
]
Jasper Rosenberg commented on WW-4165:
--
A third option would be to change UIBean.getStandardAttributes() to leverage
the @StrutsTagAttribute annotations to get the standard tag names.
Form attribute includeContext is being inserted as a dynamicAttribute
---
Key: WW-4165
URL: https://issues.apache.org/jira/browse/WW-4165
Project: Struts 2
Issue Type: Bug
Components: Other
Affects Versions: 2.3.15.1
Environment: Freemarker
Reporter: Jasper Rosenberg
Labels: form, freemarker, tags
If you use the includeContext attribute on the Form element, it shows up as
an attribute on the rendered html form. This is because
UIBean.getStandardAttributes() only includes String and list type
attributes, but includeContext is a boolean.
{code}
@s.form action=myAction includeContext=false
{code}
Can either fix by making includeContext a String (like validate is in Form),
or having UIBean.getStandardAttributes() correctly detect it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WW-4145) file.ftl in xhtml theme directly references xhtml controlfooter.ftl
[
https://issues.apache.org/jira/browse/WW-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726908#comment-13726908
]
Jasper Rosenberg commented on WW-4145:
--
Sounds good. Feel free to change the expansion token value from ~~~. Maybe
we should make it super explicit like [expandTheme]
file.ftl in xhtml theme directly references xhtml controlfooter.ftl
---
Key: WW-4145
URL: https://issues.apache.org/jira/browse/WW-4145
Project: Struts 2
Issue Type: Bug
Components: Other
Affects Versions: 2.3.15.1
Reporter: Jasper Rosenberg
Assignee: Lukasz Lenart
Labels: freemarker, tags, xhtml
Fix For: 2.3.16
Attachments: ThemeExpansion-Alt.patch, ThemeExpansion.patch
Should use $\{parameters.theme} instead so can be used in theme extension.
{code}
#include /${parameters.templateDir}/${parameters.theme}/controlheader.ftl
/
#include /${parameters.templateDir}/simple/file.ftl /
#include /${parameters.templateDir}/${parameters.theme}/controlfooter.ftl
/
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WW-4145) file.ftl in xhtml theme directly references xhtml controlfooter.ftl
[
https://issues.apache.org/jira/browse/WW-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jasper Rosenberg updated WW-4145:
-
Attachment: ThemeExpansion.patch
Here is the patch as promised. I was able to isolate it to just the
TemplateEngine.
Also, I added a new parameter so a user could change the token if it turned out
they were already using it for a different purpose.
This had a nice side effect too, that a lot of the css_xhtml templates could be
deleted because they were identical to those in its parent, xhtml.
file.ftl in xhtml theme directly references xhtml controlfooter.ftl
---
Key: WW-4145
URL: https://issues.apache.org/jira/browse/WW-4145
Project: Struts 2
Issue Type: Bug
Components: Other
Affects Versions: 2.3.15.1
Reporter: Jasper Rosenberg
Assignee: Lukasz Lenart
Labels: freemarker, tags, xhtml
Fix For: 2.3.16
Attachments: ThemeExpansion.patch
Should use $\{parameters.theme} instead so can be used in theme extension.
{code}
#include /${parameters.templateDir}/${parameters.theme}/controlheader.ftl
/
#include /${parameters.templateDir}/simple/file.ftl /
#include /${parameters.templateDir}/${parameters.theme}/controlfooter.ftl
/
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WW-4162) Don't check for diallowed ognl expressions if getting from expression cache
Jasper Rosenberg created WW-4162: Summary: Don't check for diallowed ognl expressions if getting from expression cache Key: WW-4162 URL: https://issues.apache.org/jira/browse/WW-4162 Project: Struts 2 Issue Type: Improvement Components: Expression Language Affects Versions: 2.3.15.1 Reporter: Jasper Rosenberg Priority: Minor When the ognl expression cache is enabled, when there is a cache hit, we don't need to have the overhead of traversing the tree to see if there is a disallowed expression. I've attached a simple patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WW-4162) Don't check for diallowed ognl expressions if getting from expression cache
[ https://issues.apache.org/jira/browse/WW-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jasper Rosenberg updated WW-4162: - Attachment: OgnlUtil.java.patch Patch to OgnlUtil to make it more efficient when enableExpressionCache is true, and enableEvalExpression is false (which is the default). Don't check for diallowed ognl expressions if getting from expression cache --- Key: WW-4162 URL: https://issues.apache.org/jira/browse/WW-4162 Project: Struts 2 Issue Type: Improvement Components: Expression Language Affects Versions: 2.3.15.1 Reporter: Jasper Rosenberg Priority: Minor Labels: ognl Attachments: OgnlUtil.java.patch When the ognl expression cache is enabled, when there is a cache hit, we don't need to have the overhead of traversing the tree to see if there is a disallowed expression. I've attached a simple patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WW-4144) Have ObjectFactory buildResult obey ParameterNameAware restrictions for a Result
[
https://issues.apache.org/jira/browse/WW-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723772#comment-13723772
]
Jasper Rosenberg commented on WW-4144:
--
[~lukaszlenart] Sorry, I didn't get a chance to look at the docs last week, I
was out of town. Looks good though!
Have ObjectFactory buildResult obey ParameterNameAware restrictions for a
Result
Key: WW-4144
URL: https://issues.apache.org/jira/browse/WW-4144
Project: Struts 2
Issue Type: Improvement
Components: Core Actions
Affects Versions: 2.3.15.1
Reporter: Jasper Rosenberg
Assignee: Lukasz Lenart
Priority: Minor
Labels: ObjectFactory
Fix For: 2.3.16
Attachments: WW-4144.patch
com.opensymphony.xwork2.ObjectFactory#buildResult(ResultConfig, Map), injects
all of the resultConfig parameters into the result after it has been built.
However, I'd like to be able to have my Result implement ParameterNameAware,
and then have buildResult obey its acceptableParameterName() result so I can
filter out what parameters can be injected.
I'm sorry I don't have a proper patch, but it is a very small change. Only
call setProperty on the result if it is not ParameterNameAware, or it is and
the parameter name is acceptable.
{code:java}
if ((!(result instanceof ParameterNameAware)) || (((ParameterNameAware)
result).acceptableParameterName(paramEntry.getKey( {
reflectionProvider.setProperty(paramEntry.getKey(),
paramEntry.getValue(), result, extraContext, true);
}
{code}
I have been running a Struts 2 app for 6 years with this change in place.
Just getting around to suggesting it as a patch :)
It does also look like the documentation for ParameterNameAware would need to
be updated to reflect that it can also be used for results, not just actions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
