Re: Upgrading Struts 2.2.3 to 2.3.34

2017-10-12 Thread Ej Magdaluyo
Hi Yasser, Here is the stacktrace: No result defined for action com.MyRequestAction and result fileSizeError - action com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:374) com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.ja

Re: Upgrading Struts 2.2.3 to 2.3.34

2017-10-12 Thread Lukasz Lenart
2017-10-12 3:55 GMT+02:00 Ej Magdaluyo : > No result defined for action com.MyRequestAction and result fileSizeError Can you post your action & result definition from struts.xml? Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ --

Re: Upgrading Struts 2.2.3 to 2.3.34

2017-10-12 Thread Ej Magdaluyo
Hi Lukasz, Here it is: /addAccess tiles.xml: This functionality was working correctly prior to the upgrade. I am not exactly sure what triggered the exception this time. I have already tried removing the / for this and the error persists. Your help would be greatly appreciated. Thanks

Re: Upgrading Struts 2.2.3 to 2.3.34

2017-10-12 Thread Yasser Zamani
On 10/12/2017 11:14 AM, Ej Magdaluyo wrote: > > /addAccess Your action has returned "fileSizeError" but only "success" has defined. > No result defined for action com.MyRequestAction and result fileSizeError - > action > > com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultA

Re: Upgrading Struts 2.2.3 to 2.3.34

2017-10-12 Thread Lukasz Lenart
2017-10-12 9:44 GMT+02:00 Ej Magdaluyo : > Hi Lukasz, > > Here it is: > > > /addAccess As Yasser already pointed out, you are missing a "fileSizeError" result, probably one of the interceptors returns it. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ ---

Re: Upgrading Struts 2.2.3 to 2.3.34

2017-10-12 Thread Ej Magdaluyo
HI Lukasz, Yasser, I would just like to confirm if it is expected that we would need to add a fileSizeError result. This is because the code was working in Struts 2.2.3, and the error only appeared post-migration. I reviewed the migration notes, and I am not certain which version changed this. We

Re: Upgrading Struts 2.2.3 to 2.3.34

2017-10-12 Thread Yasser Zamani
On 10/12/2017 11:44 AM, Ej Magdaluyo wrote: > I would just like to confirm if it is expected that we would need to add > a fileSizeError result. This is because the code was working in Struts > 2.2.3, and the error only appeared post-migration. I reviewed the > migration notes, and I am not ce

Re: Upgrading Struts 2.2.3 to 2.3.34

2017-10-12 Thread Lukasz Lenart
2017-10-12 10:14 GMT+02:00 Ej Magdaluyo : > I would just like to confirm if it is expected that we would need to add a fileSizeError result. This is because the code was working in Struts 2.2.3, and the error only appeared post-migration. I reviewed the migration notes, and I am not certain which v

Re: Upgrading Struts 2.2.3 to 2.3.34

2017-10-12 Thread Ej Magdaluyo
Hi Yasser, Lukasz, Thank you for the information. I will look into the code and will let you know. Here is the list of the JAR files: antlr-2.7.2.jar asm-3.3.jar asm-commons-3.3.jar asm-tree-3.3.jar commons-beanutils-1.8.0.jar commons-collections-3.2.2.jar commons-digester-2.0.jar commons-fileupl

Re: Upgrading Struts 2.2.3 to 2.3.34

2017-10-12 Thread Ej Magdaluyo
Upon investigating the interceptor flow, it should be working based on my understanding: RequestInterceptor: *import* org.apache.struts2.ServletActionContext; *import* org.apache.struts2.dispatcher.multipart.MultiPartRequestWrapper; *import* com.opensymphony.xwork2.ActionInvocation; *impor

Re: Upgrading Struts 2.2.3 to 2.3.34

2017-10-12 Thread Yasser Zamani
On 10/12/2017 4:03 PM, Ej Magdaluyo wrote: > *if*(fileRequestWrapper!=*null* &&fileRequestWrapper > .getErrors()!=*null*){ I worked and found the bug :) the new version of MultiPartRequestWrapper instantiates it's `error` inside it's constructor. So you should rewrite above as

Re: Upgrading Struts 2.2.3 to 2.3.34

2017-10-12 Thread Lukasz Lenart
2017-10-12 19:06 GMT+02:00 Yasser Zamani : > On 10/12/2017 4:03 PM, Ej Magdaluyo wrote: >> *if*(fileRequestWrapper!=*null* &&fileRequestWrapper >> .getErrors()!=*null*){ > > I worked and found the bug :) the new version of MultiPartRequestWrapper > instantiates it's `error` inside