[jira] [Commented] (WW-3993) How to implement simple CRUD application
[ https://issues.apache.org/jira/browse/WW-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979476#comment-13979476 ] Antonio Sánchez commented on WW-3993: - Is there any advance here? I can help with this, just let me know. > How to implement simple CRUD application > > > Key: WW-3993 > URL: https://issues.apache.org/jira/browse/WW-3993 > Project: Struts 2 > Issue Type: Sub-task > Components: Example Applications >Reporter: Lukasz Lenart >Assignee: Bruce Phillips >Priority: Minor > Fix For: 2.3.18 > > Attachments: crud-with-maven.7z, crud-with-maven.7z > > > Rewrite to Maven based project and with the latest Struts version > https://cwiki.apache.org/confluence/display/WW/CRUD+Demo+I -- 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] [Updated] (WW-4329) Support ConfigurationManagerListener
[ https://issues.apache.org/jira/browse/WW-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukasz Lenart updated WW-4329: -- Fix Version/s: 2.5 > 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 > Fix For: 2.5 > > > 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] [Created] (WW-4330) ServletRedirectResult and ServletActionRedirectResult do not support parameters on absolute URLs
David Waite created WW-4330: --- Summary: ServletRedirectResult and ServletActionRedirectResult do not support parameters on absolute URLs Key: WW-4330 URL: https://issues.apache.org/jira/browse/WW-4330 Project: Struts 2 Issue Type: Bug Components: Other Affects Versions: 2.3.16.1 Reporter: David Waite Attachments: 0001-Change-Servlet-Redirect-and-Servlet-Action-Redirect-.patch I noticed after an upgrade that when the location returned from the action mapper was a full absolute URL, parameters were no longer being appended. Investigating, it appears a conditional for handling context roots and namespaces expanded to also eliminate parameter and fragment/anchor appending -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (WW-4330) ServletRedirectResult and ServletActionRedirectResult do not support parameters on absolute URLs
[ https://issues.apache.org/jira/browse/WW-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Waite updated WW-4330: Attachment: 0001-Change-Servlet-Redirect-and-Servlet-Action-Redirect-.patch Fix for ServletRedirectAction and associated test mock > ServletRedirectResult and ServletActionRedirectResult do not support > parameters on absolute URLs > > > Key: WW-4330 > URL: https://issues.apache.org/jira/browse/WW-4330 > Project: Struts 2 > Issue Type: Bug > Components: Other >Affects Versions: 2.3.16.1 >Reporter: David Waite > Attachments: > 0001-Change-Servlet-Redirect-and-Servlet-Action-Redirect-.patch > > > I noticed after an upgrade that when the location returned from the action > mapper was a full absolute URL, parameters were no longer being appended. > Investigating, it appears a conditional for handling context roots and > namespaces expanded to also eliminate parameter and fragment/anchor appending -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (WW-4330) ServletRedirectResult and ServletActionRedirectResult do not support parameters on absolute URLs
[ https://issues.apache.org/jira/browse/WW-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukasz Lenart updated WW-4330: -- Fix Version/s: 2.3.18 > ServletRedirectResult and ServletActionRedirectResult do not support > parameters on absolute URLs > > > Key: WW-4330 > URL: https://issues.apache.org/jira/browse/WW-4330 > Project: Struts 2 > Issue Type: Bug > Components: Other >Affects Versions: 2.3.16.1 >Reporter: David Waite > Fix For: 2.3.18 > > Attachments: > 0001-Change-Servlet-Redirect-and-Servlet-Action-Redirect-.patch > > > I noticed after an upgrade that when the location returned from the action > mapper was a full absolute URL, parameters were no longer being appended. > Investigating, it appears a conditional for handling context roots and > namespaces expanded to also eliminate parameter and fragment/anchor appending -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (WW-4330) ServletRedirectResult and ServletActionRedirectResult do not support parameters on absolute URLs
[ https://issues.apache.org/jira/browse/WW-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980078#comment-13980078 ] Lukasz Lenart commented on WW-4330: --- The best option is to use GitHub and prepare Pull Request - we can simple review and discuss the solution then :-) > ServletRedirectResult and ServletActionRedirectResult do not support > parameters on absolute URLs > > > Key: WW-4330 > URL: https://issues.apache.org/jira/browse/WW-4330 > Project: Struts 2 > Issue Type: Bug > Components: Other >Affects Versions: 2.3.16.1 >Reporter: David Waite > Fix For: 2.3.18 > > Attachments: > 0001-Change-Servlet-Redirect-and-Servlet-Action-Redirect-.patch > > > I noticed after an upgrade that when the location returned from the action > mapper was a full absolute URL, parameters were no longer being appended. > Investigating, it appears a conditional for handling context roots and > namespaces expanded to also eliminate parameter and fragment/anchor appending -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (WW-4330) ServletRedirectResult and ServletActionRedirectResult do not support parameters on absolute URLs
[ https://issues.apache.org/jira/browse/WW-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980095#comment-13980095 ] David Waite commented on WW-4330: - Considering I created the patch off of a github checkout, that won't be difficult to pull off. > ServletRedirectResult and ServletActionRedirectResult do not support > parameters on absolute URLs > > > Key: WW-4330 > URL: https://issues.apache.org/jira/browse/WW-4330 > Project: Struts 2 > Issue Type: Bug > Components: Other >Affects Versions: 2.3.16.1 >Reporter: David Waite > Fix For: 2.3.18 > > Attachments: > 0001-Change-Servlet-Redirect-and-Servlet-Action-Redirect-.patch > > > I noticed after an upgrade that when the location returned from the action > mapper was a full absolute URL, parameters were no longer being appended. > Investigating, it appears a conditional for handling context roots and > namespaces expanded to also eliminate parameter and fragment/anchor appending -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (WW-4330) ServletRedirectResult and ServletActionRedirectResult do not support parameters on absolute URLs
[ https://issues.apache.org/jira/browse/WW-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980099#comment-13980099 ] Lukasz Lenart commented on WW-4330: --- Don't bother, next time ;-) > ServletRedirectResult and ServletActionRedirectResult do not support > parameters on absolute URLs > > > Key: WW-4330 > URL: https://issues.apache.org/jira/browse/WW-4330 > Project: Struts 2 > Issue Type: Bug > Components: Other >Affects Versions: 2.3.16.1 >Reporter: David Waite > Fix For: 2.3.18 > > Attachments: > 0001-Change-Servlet-Redirect-and-Servlet-Action-Redirect-.patch > > > I noticed after an upgrade that when the location returned from the action > mapper was a full absolute URL, parameters were no longer being appended. > Investigating, it appears a conditional for handling context roots and > namespaces expanded to also eliminate parameter and fragment/anchor appending -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (WW-4330) ServletRedirectResult and ServletActionRedirectResult do not support parameters on absolute URLs
[ https://issues.apache.org/jira/browse/WW-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980101#comment-13980101 ] ASF GitHub Bot commented on WW-4330: GitHub user dwaite opened a pull request: https://github.com/apache/struts/pull/9 Change Servlet Redirect to support absolute URLs with parameters and anchors Reported as [WW-4330](https://issues.apache.org/jira/browse/WW-4330) You can merge this pull request into a Git repository by running: $ git pull https://github.com/dwaite/struts master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/struts/pull/9.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #9 commit 50410e40a9caa58e75275f36d3a505e5335d7b88 Author: David Waite Date: 2014-04-24T18:32:44Z Change Servlet Redirect (and Servlet Action Redirect) to support absolute URLs with parameters and anchors > ServletRedirectResult and ServletActionRedirectResult do not support > parameters on absolute URLs > > > Key: WW-4330 > URL: https://issues.apache.org/jira/browse/WW-4330 > Project: Struts 2 > Issue Type: Bug > Components: Other >Affects Versions: 2.3.16.1 >Reporter: David Waite > Fix For: 2.3.18 > > Attachments: > 0001-Change-Servlet-Redirect-and-Servlet-Action-Redirect-.patch > > > I noticed after an upgrade that when the location returned from the action > mapper was a full absolute URL, parameters were no longer being appended. > Investigating, it appears a conditional for handling context roots and > namespaces expanded to also eliminate parameter and fragment/anchor appending -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (WW-4331) ConventionUnknownHandler throws null
justin miller created WW-4331: - Summary: ConventionUnknownHandler throws null Key: WW-4331 URL: https://issues.apache.org/jira/browse/WW-4331 Project: Struts 2 Issue Type: Bug Components: Plugin - Convention Affects Versions: 2.3.15.2 Environment: Tomcat 7.0.50 Java 1.7.0_40 Reporter: justin miller Priority: Minor ConventionUnknownHandler's handleUnknownActionMethod() always throws null which causes a NullPointerException when using the Rest-Plugin. This is due to RestActionMapper setting the default action method to "index" while the ConventionUnknownHandler creates an ActionSupport proxy expecting the "execute" method. Throwing null prevents the HandlerManager from handing off to the next UnknownHandler in the list, if one exists. This is related to issue WW-3368. Here's the abbreviated stack trace: java.lang.NullPointerException org.apache.struts2.convention.ConventionUnknownHandler.handleUnknownActionMethod(ConventionUnknownHandler.java:423) com.opensymphony.xwork2.DefaultUnknownHandlerManager.handleUnknownMethod(DefaultUnknownHandlerManager.java:96) com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:437) com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289) com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252) org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138) Here's the diff: 423c423 < throw null; --- > return null; -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (WW-4331) ConventionUnknownHandler throws null
[ https://issues.apache.org/jira/browse/WW-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] justin miller updated WW-4331: -- Description: ConventionUnknownHandler's handleUnknownActionMethod() always throws null which causes a NullPointerException when using the Rest-Plugin. This method is called due to RestActionMapper setting the default action method to "index" while the ConventionUnknownHandler creates an ActionSupport proxy expecting the "execute" method. Throwing null prevents the HandlerManager from handing off to the next UnknownHandler in the list, if one exists. This is related to issue WW-3368. Here's the abbreviated stack trace: java.lang.NullPointerException org.apache.struts2.convention.ConventionUnknownHandler.handleUnknownActionMethod(ConventionUnknownHandler.java:423) com.opensymphony.xwork2.DefaultUnknownHandlerManager.handleUnknownMethod(DefaultUnknownHandlerManager.java:96) com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:437) com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289) com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252) org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138) Here's the diff: 423c423 < throw null; --- > return null; was: ConventionUnknownHandler's handleUnknownActionMethod() always throws null which causes a NullPointerException when using the Rest-Plugin. This is due to RestActionMapper setting the default action method to "index" while the ConventionUnknownHandler creates an ActionSupport proxy expecting the "execute" method. Throwing null prevents the HandlerManager from handing off to the next UnknownHandler in the list, if one exists. This is related to issue WW-3368. Here's the abbreviated stack trace: java.lang.NullPointerException org.apache.struts2.convention.ConventionUnknownHandler.handleUnknownActionMethod(ConventionUnknownHandler.java:423) com.opensymphony.xwork2.DefaultUnknownHandlerManager.handleUnknownMethod(DefaultUnknownHandlerManager.java:96) com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:437) com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289) com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252) org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138) Here's the diff: 423c423 < throw null; --- > return null; > ConventionUnknownHandler throws null > > > Key: WW-4331 > URL: https://issues.apache.org/jira/browse/WW-4331 > Project: Struts 2 > Issue Type: Bug > Components: Plugin - Convention >Affects Versions: 2.3.15.2 > Environment: Tomcat 7.0.50 > Java 1.7.0_40 >Reporter: justin miller >Priority: Minor > > ConventionUnknownHandler's handleUnknownActionMethod() always throws null > which causes a NullPointerException when using the Rest-Plugin. This method > is called due to RestActionMapper setting the default action method to > "index" while the ConventionUnknownHandler creates an ActionSupport proxy > expecting the "execute" method. Throwing null prevents the HandlerManager > from handing off to the next UnknownHandler in the list, if one exists. This > is related to issue WW-3368. Here's the abbreviated stack trace: > java.lang.NullPointerException > > org.apache.struts2.convention.ConventionUnknownHandler.handleUnknownActionMethod(ConventionUnknownHandler.java:423) > > com.opensymphony.xwork2.DefaultUnknownHandlerManager.handleUnknownMethod(DefaultUnknownHandlerManager.java:96) > > com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:437) > > com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289) > > com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252) > > org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138) > Here's the diff: > 423c423 > < throw null; > --- > > return null; -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (WW-4331) ConventionUnknownHandler throws null
[
https://issues.apache.org/jira/browse/WW-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-4331:
--
Description:
ConventionUnknownHandler's handleUnknownActionMethod() always throws null which
causes a NullPointerException when using the Rest-Plugin. This method is called
due to RestActionMapper setting the default action method to "index" while the
ConventionUnknownHandler creates an ActionSupport proxy expecting the "execute"
method. Throwing null prevents the HandlerManager from handing off to the next
UnknownHandler in the list, if one exists. This is related to issue WW-3368.
Here's the abbreviated stack trace:
{noformat}
java.lang.NullPointerException
org.apache.struts2.convention.ConventionUnknownHandler.handleUnknownActionMethod(ConventionUnknownHandler.java:423)
com.opensymphony.xwork2.DefaultUnknownHandlerManager.handleUnknownMethod(DefaultUnknownHandlerManager.java:96)
com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:437)
com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289)
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252)
org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138)
{noformat}
Here's the diff:
423c423
< throw null;
---
> return null;
was:
ConventionUnknownHandler's handleUnknownActionMethod() always throws null which
causes a NullPointerException when using the Rest-Plugin. This method is called
due to RestActionMapper setting the default action method to "index" while the
ConventionUnknownHandler creates an ActionSupport proxy expecting the "execute"
method. Throwing null prevents the HandlerManager from handing off to the next
UnknownHandler in the list, if one exists. This is related to issue WW-3368.
Here's the abbreviated stack trace:
java.lang.NullPointerException
org.apache.struts2.convention.ConventionUnknownHandler.handleUnknownActionMethod(ConventionUnknownHandler.java:423)
com.opensymphony.xwork2.DefaultUnknownHandlerManager.handleUnknownMethod(DefaultUnknownHandlerManager.java:96)
com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:437)
com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289)
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252)
org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138)
Here's the diff:
423c423
< throw null;
---
> return null;
> ConventionUnknownHandler throws null
>
>
> Key: WW-4331
> URL: https://issues.apache.org/jira/browse/WW-4331
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - Convention
>Affects Versions: 2.3.15.2
> Environment: Tomcat 7.0.50
> Java 1.7.0_40
>Reporter: justin miller
>Priority: Minor
> Fix For: 2.3.18
>
>
> ConventionUnknownHandler's handleUnknownActionMethod() always throws null
> which causes a NullPointerException when using the Rest-Plugin. This method
> is called due to RestActionMapper setting the default action method to
> "index" while the ConventionUnknownHandler creates an ActionSupport proxy
> expecting the "execute" method. Throwing null prevents the HandlerManager
> from handing off to the next UnknownHandler in the list, if one exists. This
> is related to issue WW-3368. Here's the abbreviated stack trace:
> {noformat}
> java.lang.NullPointerException
>
> org.apache.struts2.convention.ConventionUnknownHandler.handleUnknownActionMethod(ConventionUnknownHandler.java:423)
>
> com.opensymphony.xwork2.DefaultUnknownHandlerManager.handleUnknownMethod(DefaultUnknownHandlerManager.java:96)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:437)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252)
>
> org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138)
> {noformat}
> Here's the diff:
> 423c423
> < throw null;
> ---
> > return null;
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (WW-4331) ConventionUnknownHandler throws null
[
https://issues.apache.org/jira/browse/WW-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-4331:
--
Fix Version/s: 2.3.18
> ConventionUnknownHandler throws null
>
>
> Key: WW-4331
> URL: https://issues.apache.org/jira/browse/WW-4331
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - Convention
>Affects Versions: 2.3.15.2
> Environment: Tomcat 7.0.50
> Java 1.7.0_40
>Reporter: justin miller
>Priority: Minor
> Fix For: 2.3.18
>
>
> ConventionUnknownHandler's handleUnknownActionMethod() always throws null
> which causes a NullPointerException when using the Rest-Plugin. This method
> is called due to RestActionMapper setting the default action method to
> "index" while the ConventionUnknownHandler creates an ActionSupport proxy
> expecting the "execute" method. Throwing null prevents the HandlerManager
> from handing off to the next UnknownHandler in the list, if one exists. This
> is related to issue WW-3368. Here's the abbreviated stack trace:
> {noformat}
> java.lang.NullPointerException
>
> org.apache.struts2.convention.ConventionUnknownHandler.handleUnknownActionMethod(ConventionUnknownHandler.java:423)
>
> com.opensymphony.xwork2.DefaultUnknownHandlerManager.handleUnknownMethod(DefaultUnknownHandlerManager.java:96)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:437)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252)
>
> org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138)
> {noformat}
> Here's the diff:
> 423c423
> < throw null;
> ---
> > return null;
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (WW-4331) ConventionUnknownHandler throws null
[
https://issues.apache.org/jira/browse/WW-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980203#comment-13980203
]
Lukasz Lenart commented on WW-4331:
---
I assume the solution is to return null instead throwing null?
> ConventionUnknownHandler throws null
>
>
> Key: WW-4331
> URL: https://issues.apache.org/jira/browse/WW-4331
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - Convention
>Affects Versions: 2.3.15.2
> Environment: Tomcat 7.0.50
> Java 1.7.0_40
>Reporter: justin miller
>Priority: Minor
> Fix For: 2.3.18
>
>
> ConventionUnknownHandler's handleUnknownActionMethod() always throws null
> which causes a NullPointerException when using the Rest-Plugin. This method
> is called due to RestActionMapper setting the default action method to
> "index" while the ConventionUnknownHandler creates an ActionSupport proxy
> expecting the "execute" method. Throwing null prevents the HandlerManager
> from handing off to the next UnknownHandler in the list, if one exists. This
> is related to issue WW-3368. Here's the abbreviated stack trace:
> {noformat}
> java.lang.NullPointerException
>
> org.apache.struts2.convention.ConventionUnknownHandler.handleUnknownActionMethod(ConventionUnknownHandler.java:423)
>
> com.opensymphony.xwork2.DefaultUnknownHandlerManager.handleUnknownMethod(DefaultUnknownHandlerManager.java:96)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:437)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252)
>
> org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138)
> {noformat}
> Here's the diff:
> 423c423
> < throw null;
> ---
> > return null;
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (WW-4331) ConventionUnknownHandler throws null
[
https://issues.apache.org/jira/browse/WW-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
justin miller updated WW-4331:
--
Description:
ConventionUnknownHandler's handleUnknownActionMethod() always throws null which
causes a NullPointerException when using the Rest-Plugin. This method is called
due to RestActionMapper setting the default action method to "index" while the
ConventionUnknownHandler creates an ActionSupport proxy expecting the "execute"
method. Throwing null prevents the HandlerManager from handing off to the next
UnknownHandler in the list, if one exists. This is related to issue WW-3368.
Here's the abbreviated stack trace:
{noformat}
java.lang.NullPointerException
org.apache.struts2.convention.ConventionUnknownHandler.handleUnknownActionMethod(ConventionUnknownHandler.java:423)
com.opensymphony.xwork2.DefaultUnknownHandlerManager.handleUnknownMethod(DefaultUnknownHandlerManager.java:96)
com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:437)
com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289)
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252)
org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138)
{noformat}
Here's the patch:
423c423
< throw null;
---
> return null;
was:
ConventionUnknownHandler's handleUnknownActionMethod() always throws null which
causes a NullPointerException when using the Rest-Plugin. This method is called
due to RestActionMapper setting the default action method to "index" while the
ConventionUnknownHandler creates an ActionSupport proxy expecting the "execute"
method. Throwing null prevents the HandlerManager from handing off to the next
UnknownHandler in the list, if one exists. This is related to issue WW-3368.
Here's the abbreviated stack trace:
{noformat}
java.lang.NullPointerException
org.apache.struts2.convention.ConventionUnknownHandler.handleUnknownActionMethod(ConventionUnknownHandler.java:423)
com.opensymphony.xwork2.DefaultUnknownHandlerManager.handleUnknownMethod(DefaultUnknownHandlerManager.java:96)
com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:437)
com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289)
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252)
org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138)
{noformat}
Here's the diff:
423c423
< throw null;
---
> return null;
> ConventionUnknownHandler throws null
>
>
> Key: WW-4331
> URL: https://issues.apache.org/jira/browse/WW-4331
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - Convention
>Affects Versions: 2.3.15.2
> Environment: Tomcat 7.0.50
> Java 1.7.0_40
>Reporter: justin miller
>Priority: Minor
> Fix For: 2.3.18
>
>
> ConventionUnknownHandler's handleUnknownActionMethod() always throws null
> which causes a NullPointerException when using the Rest-Plugin. This method
> is called due to RestActionMapper setting the default action method to
> "index" while the ConventionUnknownHandler creates an ActionSupport proxy
> expecting the "execute" method. Throwing null prevents the HandlerManager
> from handing off to the next UnknownHandler in the list, if one exists. This
> is related to issue WW-3368. Here's the abbreviated stack trace:
> {noformat}
> java.lang.NullPointerException
>
> org.apache.struts2.convention.ConventionUnknownHandler.handleUnknownActionMethod(ConventionUnknownHandler.java:423)
>
> com.opensymphony.xwork2.DefaultUnknownHandlerManager.handleUnknownMethod(DefaultUnknownHandlerManager.java:96)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:437)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252)
>
> org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138)
> {noformat}
> Here's the patch:
> 423c423
> < throw null;
> ---
> > return null;
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (WW-4331) ConventionUnknownHandler throws null
[
https://issues.apache.org/jira/browse/WW-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980250#comment-13980250
]
justin miller commented on WW-4331:
---
yes sorry. returning null allows the HandlerManager to move on to the next
Handler
> ConventionUnknownHandler throws null
>
>
> Key: WW-4331
> URL: https://issues.apache.org/jira/browse/WW-4331
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - Convention
>Affects Versions: 2.3.15.2
> Environment: Tomcat 7.0.50
> Java 1.7.0_40
>Reporter: justin miller
>Priority: Minor
> Fix For: 2.3.18
>
>
> ConventionUnknownHandler's handleUnknownActionMethod() always throws null
> which causes a NullPointerException when using the Rest-Plugin. This method
> is called due to RestActionMapper setting the default action method to
> "index" while the ConventionUnknownHandler creates an ActionSupport proxy
> expecting the "execute" method. Throwing null prevents the HandlerManager
> from handing off to the next UnknownHandler in the list, if one exists. This
> is related to issue WW-3368. Here's the abbreviated stack trace:
> {noformat}
> java.lang.NullPointerException
>
> org.apache.struts2.convention.ConventionUnknownHandler.handleUnknownActionMethod(ConventionUnknownHandler.java:423)
>
> com.opensymphony.xwork2.DefaultUnknownHandlerManager.handleUnknownMethod(DefaultUnknownHandlerManager.java:96)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:437)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289)
>
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252)
>
> org.apache.struts2.rest.RestActionInvocation.invoke(RestActionInvocation.java:138)
> {noformat}
> Here's the patch:
> 423c423
> < throw null;
> ---
> > return null;
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (WW-4330) ServletRedirectResult and ServletActionRedirectResult do not support parameters on absolute URLs
[ https://issues.apache.org/jira/browse/WW-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980333#comment-13980333 ] ASF GitHub Bot commented on WW-4330: GitHub user dwaite opened a pull request: https://github.com/apache/struts/pull/10 Change Servlet Redirect to support absolute URLs with parameters and anchors Reported as [WW-4330](https://issues.apache.org/jira/browse/WW-4330) You can merge this pull request into a Git repository by running: $ git pull https://github.com/dwaite/struts develop Alternatively you can review and apply these changes as the patch at: https://github.com/apache/struts/pull/10.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #10 commit de31001a266ae9e122ec1747c8ae1c9a8ee20e51 Author: David Waite Date: 2014-04-24T21:31:14Z Change Servlet Redirect (and Servlet Action Redirect) to support absolute URLs with parameters and anchors > ServletRedirectResult and ServletActionRedirectResult do not support > parameters on absolute URLs > > > Key: WW-4330 > URL: https://issues.apache.org/jira/browse/WW-4330 > Project: Struts 2 > Issue Type: Bug > Components: Other >Affects Versions: 2.3.16.1 >Reporter: David Waite > Fix For: 2.3.18 > > Attachments: > 0001-Change-Servlet-Redirect-and-Servlet-Action-Redirect-.patch > > > I noticed after an upgrade that when the location returned from the action > mapper was a full absolute URL, parameters were no longer being appended. > Investigating, it appears a conditional for handling context roots and > namespaces expanded to also eliminate parameter and fragment/anchor appending -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (WW-4330) ServletRedirectResult and ServletActionRedirectResult do not support parameters on absolute URLs
[ https://issues.apache.org/jira/browse/WW-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980334#comment-13980334 ] ASF GitHub Bot commented on WW-4330: Github user dwaite closed the pull request at: https://github.com/apache/struts/pull/9 > ServletRedirectResult and ServletActionRedirectResult do not support > parameters on absolute URLs > > > Key: WW-4330 > URL: https://issues.apache.org/jira/browse/WW-4330 > Project: Struts 2 > Issue Type: Bug > Components: Other >Affects Versions: 2.3.16.1 >Reporter: David Waite > Fix For: 2.3.18 > > Attachments: > 0001-Change-Servlet-Redirect-and-Servlet-Action-Redirect-.patch > > > I noticed after an upgrade that when the location returned from the action > mapper was a full absolute URL, parameters were no longer being appended. > Investigating, it appears a conditional for handling context roots and > namespaces expanded to also eliminate parameter and fragment/anchor appending -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (WW-4332) refine excludeParams of ParametersInterceptor to improve security
zhouyanming created WW-4332:
---
Summary: refine excludeParams of ParametersInterceptor to improve
security
Key: WW-4332
URL: https://issues.apache.org/jira/browse/WW-4332
Project: Struts 2
Issue Type: Improvement
Components: Core Interceptors
Reporter: zhouyanming
Priority: Critical
{code}
(.*\.|^)class\..*
{code}
should be
{code}
(.*\.|^)class(\.|\[).*,.*\['class'\](\.|\[).*,.*\["class"\](\.|\[).*
{code}
it will block such as
{code}class['classLoader'] , model['class'].classLoader ,
model["class"].classLoader {code}
I think use regex to block parameterName is not best solution,It must be done
in ValueStack, seperate entry point , one for serverside, one for client
side,client side should add more restriction and security checks.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (WW-4332) refine excludeParams of ParametersInterceptor to improve security
[
https://issues.apache.org/jira/browse/WW-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-4332:
--
Affects Version/s: 2.3.16.1
> refine excludeParams of ParametersInterceptor to improve security
> --
>
> Key: WW-4332
> URL: https://issues.apache.org/jira/browse/WW-4332
> Project: Struts 2
> Issue Type: Improvement
> Components: Core Interceptors
>Affects Versions: 2.3.16.1
>Reporter: zhouyanming
>Priority: Critical
> Fix For: 2.3.16.2
>
>
> {code}
> (.*\.|^)class\..*
> {code}
> should be
> {code}
> (.*\.|^)class(\.|\[).*,.*\['class'\](\.|\[).*,.*\["class"\](\.|\[).*
> {code}
> it will block such as
> {code}class['classLoader'] , model['class'].classLoader ,
> model["class"].classLoader {code}
> I think use regex to block parameterName is not best solution,It must be done
> in ValueStack, seperate entry point , one for serverside, one for client
> side,client side should add more restriction and security checks.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (WW-4332) refine excludeParams of ParametersInterceptor to improve security
[
https://issues.apache.org/jira/browse/WW-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-4332:
--
Fix Version/s: 2.3.16.2
> refine excludeParams of ParametersInterceptor to improve security
> --
>
> Key: WW-4332
> URL: https://issues.apache.org/jira/browse/WW-4332
> Project: Struts 2
> Issue Type: Improvement
> Components: Core Interceptors
>Affects Versions: 2.3.16.1
>Reporter: zhouyanming
>Priority: Critical
> Fix For: 2.3.16.2
>
>
> {code}
> (.*\.|^)class\..*
> {code}
> should be
> {code}
> (.*\.|^)class(\.|\[).*,.*\['class'\](\.|\[).*,.*\["class"\](\.|\[).*
> {code}
> it will block such as
> {code}class['classLoader'] , model['class'].classLoader ,
> model["class"].classLoader {code}
> I think use regex to block parameterName is not best solution,It must be done
> in ValueStack, seperate entry point , one for serverside, one for client
> side,client side should add more restriction and security checks.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (WW-4332) refine excludeParams of ParametersInterceptor to improve security
[
https://issues.apache.org/jira/browse/WW-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart closed WW-4332.
-
Resolution: Fixed
Assignee: Lukasz Lenart
Thanks for your report, but this was already implemented in a fast-track
release which is under Vote now.
> refine excludeParams of ParametersInterceptor to improve security
> --
>
> Key: WW-4332
> URL: https://issues.apache.org/jira/browse/WW-4332
> Project: Struts 2
> Issue Type: Improvement
> Components: Core Interceptors
>Affects Versions: 2.3.16.1
>Reporter: zhouyanming
>Assignee: Lukasz Lenart
>Priority: Critical
> Fix For: 2.3.16.2
>
>
> {code}
> (.*\.|^)class\..*
> {code}
> should be
> {code}
> (.*\.|^)class(\.|\[).*,.*\['class'\](\.|\[).*,.*\["class"\](\.|\[).*
> {code}
> it will block such as
> {code}class['classLoader'] , model['class'].classLoader ,
> model["class"].classLoader {code}
> I think use regex to block parameterName is not best solution,It must be done
> in ValueStack, seperate entry point , one for serverside, one for client
> side,client side should add more restriction and security checks.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
