[jira] [Commented] (WW-4507) Struts 2 XSS vulnerability with
[ https://issues.apache.org/jira/browse/WW-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217656#comment-15217656 ] Rene Gielen commented on WW-4507: - [~taromaru] I'm not sure if my analysis above is completely wrong. However, this is an interesting finding and I see your point. Historically we had many issues with solely relying on "standard" encoding querying functions like response.getCharacterEncoding(). That's why the struts.i18n.encoding property was introduced (originally even in webwork). With its help we force a user configurable encoding. Users are responsible for configuring consistent encoding, that is having page encoding match their Struts 2 setup. The best solution to your point is IMO to use consistent encoding both in page encoding, connector setup and struts.i18n.encoding. Besides that, we recommend to use UTF-8 only. See also https://struts.apache.org/docs/s2-028.html This particular issue WW-4507 deals with a platform problem. After talking to the Tomcat guys, we agreed to add additional safety by using their encoding logic where applies to framework calls. But we also said: this is a platform issue, please move to a supported JRE. There is a reason why the old decoding rule was ditched, so we can only encourage our users to move to a modern and less buggy environment. If you feel like the Include component should use response.getCharacterEncoding rather than struts.i18n.encoding, you are invited to open a new issue to let us discuss this, along with possible implications. > Struts 2 XSS vulnerability with > - > > Key: WW-4507 > URL: https://issues.apache.org/jira/browse/WW-4507 > Project: Struts 2 > Issue Type: Bug >Affects Versions: 2.3.16.3 > Environment: Operating System: Windows 7. Application Server: > JBoss-4.2.1.GA. Java: jdk1.5.0.11. Developloment Framework: Struts > 2.3.16.3. Browser: FireFox 38.0.1 >Reporter: brian neisen >Assignee: Rene Gielen > Labels: struts2, vulnerability, xss > Fix For: 2.3.28, 2.5 > > > WhiteHat Security (whitehatsec.com) has found an xss vulnerability with the > tag. When loading a url in a browser with some param name, in > this case "myinput", and the jsp being loaded has the tag name="myinput" id="myinput">, an alert message is popped open > in the browser- which is WhiteHat's method of showing the vulnerability. > Example url is: > [http://localhost:8080/sample.action?myinput=%fc%80%80%80%80%a2%fc%80%80%80%80%bE%FC%80%80%80%80%BC%FC%80%80%80%81%B7%FC%80%80%80%81%A8%FC%80%80%80%81%B3%FC%80%80%80%81%A3%FC%80%80%80%81%A8%FC%80%80%80%81%A5%FC%80%80%80%81%A3%FC%80%80%80%81%AB%FC%80%80%80%80%BE%fc%80%80%80%80%bCscript%fc%80%80%80%80%bEalert%fc%80%80%80%80%a81%fc%80%80%80%80%a9%fc%80%80%80%80%bC%fc%80%80%80%80%aFscript%fc%80%80%80%80%bE] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4507) Struts 2 XSS vulnerability with
[ https://issues.apache.org/jira/browse/WW-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15178408#comment-15178408 ] Rene Gielen commented on WW-4507: - [~lukaszlenart] done, sorra for not resolving the issue > Struts 2 XSS vulnerability with > - > > Key: WW-4507 > URL: https://issues.apache.org/jira/browse/WW-4507 > Project: Struts 2 > Issue Type: Bug >Affects Versions: 2.3.16.3 > Environment: Operating System: Windows 7. Application Server: > JBoss-4.2.1.GA. Java: jdk1.5.0.11. Developloment Framework: Struts > 2.3.16.3. Browser: FireFox 38.0.1 >Reporter: brian neisen >Assignee: Rene Gielen > Labels: struts2, vulnerability, xss > Fix For: 2.3.25, 2.5 > > > WhiteHat Security (whitehatsec.com) has found an xss vulnerability with the > tag. When loading a url in a browser with some param name, in > this case "myinput", and the jsp being loaded has the tag name="myinput" id="myinput">, an alert message is popped open > in the browser- which is WhiteHat's method of showing the vulnerability. > Example url is: > [http://localhost:8080/sample.action?myinput=%fc%80%80%80%80%a2%fc%80%80%80%80%bE%FC%80%80%80%80%BC%FC%80%80%80%81%B7%FC%80%80%80%81%A8%FC%80%80%80%81%B3%FC%80%80%80%81%A3%FC%80%80%80%81%A8%FC%80%80%80%81%A5%FC%80%80%80%81%A3%FC%80%80%80%81%AB%FC%80%80%80%80%BE%fc%80%80%80%80%bCscript%fc%80%80%80%80%bEalert%fc%80%80%80%80%a81%fc%80%80%80%80%a9%fc%80%80%80%80%bC%fc%80%80%80%80%aFscript%fc%80%80%80%80%bE] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (WW-4507) Struts 2 XSS vulnerability with
[ https://issues.apache.org/jira/browse/WW-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15178408#comment-15178408 ] Rene Gielen edited comment on WW-4507 at 3/3/16 7:16 PM: - [~lukaszlenart] done, sorry for not resolving the issue was (Author: rgielen): [~lukaszlenart] done, sorra for not resolving the issue > Struts 2 XSS vulnerability with > - > > Key: WW-4507 > URL: https://issues.apache.org/jira/browse/WW-4507 > Project: Struts 2 > Issue Type: Bug >Affects Versions: 2.3.16.3 > Environment: Operating System: Windows 7. Application Server: > JBoss-4.2.1.GA. Java: jdk1.5.0.11. Developloment Framework: Struts > 2.3.16.3. Browser: FireFox 38.0.1 >Reporter: brian neisen >Assignee: Rene Gielen > Labels: struts2, vulnerability, xss > Fix For: 2.3.25, 2.5 > > > WhiteHat Security (whitehatsec.com) has found an xss vulnerability with the > tag. When loading a url in a browser with some param name, in > this case "myinput", and the jsp being loaded has the tag name="myinput" id="myinput">, an alert message is popped open > in the browser- which is WhiteHat's method of showing the vulnerability. > Example url is: > [http://localhost:8080/sample.action?myinput=%fc%80%80%80%80%a2%fc%80%80%80%80%bE%FC%80%80%80%80%BC%FC%80%80%80%81%B7%FC%80%80%80%81%A8%FC%80%80%80%81%B3%FC%80%80%80%81%A3%FC%80%80%80%81%A8%FC%80%80%80%81%A5%FC%80%80%80%81%A3%FC%80%80%80%81%AB%FC%80%80%80%80%BE%fc%80%80%80%80%bCscript%fc%80%80%80%80%bEalert%fc%80%80%80%80%a81%fc%80%80%80%80%a9%fc%80%80%80%80%bC%fc%80%80%80%80%aFscript%fc%80%80%80%80%bE] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (WW-4507) Struts 2 XSS vulnerability with
[ https://issues.apache.org/jira/browse/WW-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen resolved WW-4507. - Resolution: Fixed > Struts 2 XSS vulnerability with > - > > Key: WW-4507 > URL: https://issues.apache.org/jira/browse/WW-4507 > Project: Struts 2 > Issue Type: Bug >Affects Versions: 2.3.16.3 > Environment: Operating System: Windows 7. Application Server: > JBoss-4.2.1.GA. Java: jdk1.5.0.11. Developloment Framework: Struts > 2.3.16.3. Browser: FireFox 38.0.1 >Reporter: brian neisen >Assignee: Rene Gielen > Labels: struts2, vulnerability, xss > Fix For: 2.3.25, 2.5 > > > WhiteHat Security (whitehatsec.com) has found an xss vulnerability with the > tag. When loading a url in a browser with some param name, in > this case "myinput", and the jsp being loaded has the tag name="myinput" id="myinput">, an alert message is popped open > in the browser- which is WhiteHat's method of showing the vulnerability. > Example url is: > [http://localhost:8080/sample.action?myinput=%fc%80%80%80%80%a2%fc%80%80%80%80%bE%FC%80%80%80%80%BC%FC%80%80%80%81%B7%FC%80%80%80%81%A8%FC%80%80%80%81%B3%FC%80%80%80%81%A3%FC%80%80%80%81%A8%FC%80%80%80%81%A5%FC%80%80%80%81%A3%FC%80%80%80%81%AB%FC%80%80%80%80%BE%fc%80%80%80%80%bCscript%fc%80%80%80%80%bEalert%fc%80%80%80%80%a81%fc%80%80%80%80%a9%fc%80%80%80%80%bC%fc%80%80%80%80%aFscript%fc%80%80%80%80%bE] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WW-4507) Struts 2 XSS vulnerability with
[ https://issues.apache.org/jira/browse/WW-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen updated WW-4507: Fix Version/s: 2.5 > Struts 2 XSS vulnerability with > - > > Key: WW-4507 > URL: https://issues.apache.org/jira/browse/WW-4507 > Project: Struts 2 > Issue Type: Bug >Affects Versions: 2.3.16.3 > Environment: Operating System: Windows 7. Application Server: > JBoss-4.2.1.GA. Java: jdk1.5.0.11. Developloment Framework: Struts > 2.3.16.3. Browser: FireFox 38.0.1 >Reporter: brian neisen >Assignee: Rene Gielen > Labels: struts2, vulnerability, xss > Fix For: 2.3.x, 2.5 > > > WhiteHat Security (whitehatsec.com) has found an xss vulnerability with the > tag. When loading a url in a browser with some param name, in > this case "myinput", and the jsp being loaded has the tag name="myinput" id="myinput">, an alert message is popped open > in the browser- which is WhiteHat's method of showing the vulnerability. > Example url is: > [http://localhost:8080/sample.action?myinput=%fc%80%80%80%80%a2%fc%80%80%80%80%bE%FC%80%80%80%80%BC%FC%80%80%80%81%B7%FC%80%80%80%81%A8%FC%80%80%80%81%B3%FC%80%80%80%81%A3%FC%80%80%80%81%A8%FC%80%80%80%81%A5%FC%80%80%80%81%A3%FC%80%80%80%81%AB%FC%80%80%80%80%BE%fc%80%80%80%80%bCscript%fc%80%80%80%80%bEalert%fc%80%80%80%80%a81%fc%80%80%80%80%a9%fc%80%80%80%80%bC%fc%80%80%80%80%aFscript%fc%80%80%80%80%bE] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (WW-4507) Struts 2 XSS vulnerability with
[ https://issues.apache.org/jira/browse/WW-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen reassigned WW-4507: --- Assignee: Rene Gielen > Struts 2 XSS vulnerability with > - > > Key: WW-4507 > URL: https://issues.apache.org/jira/browse/WW-4507 > Project: Struts 2 > Issue Type: Bug >Affects Versions: 2.3.16.3 > Environment: Operating System: Windows 7. Application Server: > JBoss-4.2.1.GA. Java: jdk1.5.0.11. Developloment Framework: Struts > 2.3.16.3. Browser: FireFox 38.0.1 >Reporter: brian neisen >Assignee: Rene Gielen > Labels: struts2, vulnerability, xss > Fix For: 2.3.x > > > WhiteHat Security (whitehatsec.com) has found an xss vulnerability with the > tag. When loading a url in a browser with some param name, in > this case "myinput", and the jsp being loaded has the tag name="myinput" id="myinput">, an alert message is popped open > in the browser- which is WhiteHat's method of showing the vulnerability. > Example url is: > [http://localhost:8080/sample.action?myinput=%fc%80%80%80%80%a2%fc%80%80%80%80%bE%FC%80%80%80%80%BC%FC%80%80%80%81%B7%FC%80%80%80%81%A8%FC%80%80%80%81%B3%FC%80%80%80%81%A3%FC%80%80%80%81%A8%FC%80%80%80%81%A5%FC%80%80%80%81%A3%FC%80%80%80%81%AB%FC%80%80%80%80%BE%fc%80%80%80%80%bCscript%fc%80%80%80%80%bEalert%fc%80%80%80%80%a81%fc%80%80%80%80%a9%fc%80%80%80%80%bC%fc%80%80%80%80%aFscript%fc%80%80%80%80%bE] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (WW-4403) JDK 8: build fails due to JavaDoc checking issues
[
https://issues.apache.org/jira/browse/WW-4403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen resolved WW-4403.
-
Resolution: Fixed
Assignee: Rene Gielen
Fix Version/s: 2.3.25
An automatically activated profile for JDK8 builds was introduced, configuring
maven-javadoc-plugin to disable breaking javadoc lint checking
> JDK 8: build fails due to JavaDoc checking issues
> -
>
> Key: WW-4403
> URL: https://issues.apache.org/jira/browse/WW-4403
> Project: Struts 2
> Issue Type: Bug
> Components: Build Management
>Affects Versions: 2.3.16.3
>Reporter: Rene Gielen
>Assignee: Rene Gielen
> Labels: jdk8
> Fix For: 2.3.25, 2.5
>
>
> JDK 8 introduced stricter checking for JavaDoc processing, causing issues
> formerly producing warning messages to break the build.
> Basically the fix is as easy as adding the following configuration to the
> pluginManagement section:
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.9.1
>
> private
> -Xdoclint:none
>
>
> {code}
> To fix and close this issue, we need a testable build though which is
> currently blocked by WW-4402
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (WW-4381) upgrade to jasperreports 6.0
[ https://issues.apache.org/jira/browse/WW-4381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen resolved WW-4381. - Resolution: Fixed excluded dependencies that are not served from Maven Central and that are not needed during build > upgrade to jasperreports 6.0 > > > Key: WW-4381 > URL: https://issues.apache.org/jira/browse/WW-4381 > Project: Struts 2 > Issue Type: Improvement > Components: Plugin - JasperReports >Reporter: zhouyanming >Assignee: Rene Gielen > Fix For: 2.5 > > > JasperReportsResult.java is not compatible with jasperreports 6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4507) Struts 2 XSS vulnerability with
[ https://issues.apache.org/jira/browse/WW-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098308#comment-15098308 ] Rene Gielen commented on WW-4507: - We can confirm now that this is a platform issue. Especially JRE 1.5's URLDecoder implementation seems to be broken to the point that this non-spec encoding isn't rejected / filtered. The current implementation of URLDecoder in JRE 1.8 seems to address all issues in this space, thus it is highly recommended to upgrade to JRE 1.8 for production environments Some containers such as Tomcat and Jetty circumvent broken JRE URLDecoder implementations by providing their own decoder for dealing with request parameters. JBoss 4.2.1 does not seem to be in this space. While upcoming Struts 2.3.25 will have improved handling for some edge cases where URLDecoder is called by using Tomcat's UDecoder solution, this will not address the specific issue mentioned here. To address this, one will either have to upgrade the JRE to a version with non-broken URLDecoder implementation (preferably JRE 1.8) or a container that circumvents calls to broken URLDecoder implementation calls in it's Servlet API implementation. > Struts 2 XSS vulnerability with > - > > Key: WW-4507 > URL: https://issues.apache.org/jira/browse/WW-4507 > Project: Struts 2 > Issue Type: Bug >Affects Versions: 2.3.16.3 > Environment: Operating System: Windows 7. Application Server: > JBoss-4.2.1.GA. Java: jdk1.5.0.11. Developloment Framework: Struts > 2.3.16.3. Browser: FireFox 38.0.1 >Reporter: brian neisen > Labels: struts2, vulnerability, xss > Fix For: 2.3.x > > > WhiteHat Security (whitehatsec.com) has found an xss vulnerability with the > tag. When loading a url in a browser with some param name, in > this case "myinput", and the jsp being loaded has the tag name="myinput" id="myinput">, an alert message is popped open > in the browser- which is WhiteHat's method of showing the vulnerability. > Example url is: > [http://localhost:8080/sample.action?myinput=%fc%80%80%80%80%a2%fc%80%80%80%80%bE%FC%80%80%80%80%BC%FC%80%80%80%81%B7%FC%80%80%80%81%A8%FC%80%80%80%81%B3%FC%80%80%80%81%A3%FC%80%80%80%81%A8%FC%80%80%80%81%A5%FC%80%80%80%81%A3%FC%80%80%80%81%AB%FC%80%80%80%80%BE%fc%80%80%80%80%bCscript%fc%80%80%80%80%bEalert%fc%80%80%80%80%a81%fc%80%80%80%80%a9%fc%80%80%80%80%bC%fc%80%80%80%80%aFscript%fc%80%80%80%80%bE] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (WW-4381) upgrade to jasperreports 6.0
[ https://issues.apache.org/jira/browse/WW-4381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen reopened WW-4381: - Assignee: Rene Gielen Jasper Reports 6 unfortunately introduces custom repositories in its pom to provide a source for org.olap4j:olap4j which cannot be found in an official repository. This break builds on systems behind a Maven mirror. The solution is to exclude this dependency, since it is not required at compile time. Jasper Reports is marked as provided within the plugin, such that the end user is responsible for providing it in his project build. > upgrade to jasperreports 6.0 > > > Key: WW-4381 > URL: https://issues.apache.org/jira/browse/WW-4381 > Project: Struts 2 > Issue Type: Improvement > Components: Plugin - JasperReports >Reporter: zhouyanming >Assignee: Rene Gielen > Fix For: 2.5 > > > JasperReportsResult.java is not compatible with jasperreports 6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4507) Struts 2 XSS vulnerability with
[ https://issues.apache.org/jira/browse/WW-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15082735#comment-15082735 ] Rene Gielen commented on WW-4507: - I have tried to reproduce this with a page encoding of ISO-8859-1 on Tomcat 7, JDK 8, Struts 2.3.24.1, Chrome - to no success Just to clarify: can we confirm that this is no general issue with ISO-8859-1 page encoding usage? It looks to me like a very specific behaviour found in [~greaser...@gmail.com]'s setup, including the usage of an older Struts version which is no longer supported due to security fix upgrade policy? > Struts 2 XSS vulnerability with > - > > Key: WW-4507 > URL: https://issues.apache.org/jira/browse/WW-4507 > Project: Struts 2 > Issue Type: Bug >Affects Versions: 2.3.16.3 > Environment: Operating System: Windows 7. Application Server: > JBoss-4.2.1.GA. Java: jdk1.5.0.11. Developloment Framework: Struts > 2.3.16.3. Browser: FireFox 38.0.1 >Reporter: brian neisen > Labels: struts2, vulnerability, xss > Fix For: 2.3.x > > > WhiteHat Security (whitehatsec.com) has found an xss vulnerability with the > tag. When loading a url in a browser with some param name, in > this case "myinput", and the jsp being loaded has the tag name="myinput" id="myinput">, an alert message is popped open > in the browser- which is WhiteHat's method of showing the vulnerability. > Example url is: > [http://localhost:8080/sample.action?myinput=%fc%80%80%80%80%a2%fc%80%80%80%80%bE%FC%80%80%80%80%BC%FC%80%80%80%81%B7%FC%80%80%80%81%A8%FC%80%80%80%81%B3%FC%80%80%80%81%A3%FC%80%80%80%81%A8%FC%80%80%80%81%A5%FC%80%80%80%81%A3%FC%80%80%80%81%AB%FC%80%80%80%80%BE%fc%80%80%80%80%bCscript%fc%80%80%80%80%bEalert%fc%80%80%80%80%a81%fc%80%80%80%80%a9%fc%80%80%80%80%bC%fc%80%80%80%80%aFscript%fc%80%80%80%80%bE] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (WW-4559) Define a bean of java.io.FileInputStream in Spring makes the Struts stream result not work
[
https://issues.apache.org/jira/browse/WW-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-4559:
Priority: Minor (was: Major)
> Define a bean of java.io.FileInputStream in Spring makes the Struts stream
> result not work
> --
>
> Key: WW-4559
> URL: https://issues.apache.org/jira/browse/WW-4559
> Project: Struts 2
> Issue Type: Bug
> Components: Dispatch Filter
>Reporter: Alireza Fattahi
>Priority: Minor
> Fix For: 2.3.x
>
>
> In a strust2 + Spring 4 project
> Consider a simple action with stream result
> {code:title=Bar.java|borderStyle=solid}
> @Action(value = "sample-export",
> results = { @Result(name = "success", type = "stream", params = {
> "inputName", "exportInputStream", "contentType",
> "${exportContentType}; charset=UTF-8", "Content-Disposition",
> "attachment; filename=\"${filename}\"", "contentDisposition",
> "attachment; filename=\"${filename}\"", "bufferSize", "2048" }) })
> public String export() throws ClientException {
> //buildExportInputStream() creates and returns new ByteArrayOutputStream
> by using jasper
> exportInputStream = buildExportInputStream();
> LOG.debug("Exporting to {} file ", getFilename());
> return SUCCESS;
> }
> {code}
> This works fine,
> Now define a bean
> {code:xml}
>
>
>
> {code}
> The export will not work correctly any more, first time you get the
> c:/sample.jks as file and then an error which same stream already closed.
> I have found that the sampleStream will be autowired to
> org.apache.struts2.dispatcher.StreamResult and I see this log:
> {panel:title=LOG|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> DEBUG ort.DefaultListableBeanFactory Returning cached instance of singleton
> bean 'sampleStream'
> DEBUG ort.DefaultListableBeanFactory Autowiring by type from bean name
> 'org.apache.struts2.dispatcher.StreamResult' via constructor to bean named
> 'sampleStream'
> {panel}
> This mistaken autowired is the source of problem ! Is there any workaround.
> And by the way, why the sampleStream is autowired here !
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4559) Define a bean of java.io.FileInputStream in Spring makes the Struts stream result not work
[
https://issues.apache.org/jira/browse/WW-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14989110#comment-14989110
]
Rene Gielen commented on WW-4559:
-
Struts treats dependency injection as a first class citizen, so injection
candidates are respected even in framework classes. I think your case is quite
special, since I've never seen someone declaring an InputStream as managed bean
before. I must also admit that I doubt this is a best practice.
Anyway, we might want to look into this to check wether such an injection of a
matching managed bean is viable in StreamResult or should be prevented.
I don't see particular problems arise from setting alwaysRespect=true. Since
the advent of @Inject I'd always prefer to limit autowiring where possible in
favor for explicit declarations.
> Define a bean of java.io.FileInputStream in Spring makes the Struts stream
> result not work
> --
>
> Key: WW-4559
> URL: https://issues.apache.org/jira/browse/WW-4559
> Project: Struts 2
> Issue Type: Bug
> Components: Dispatch Filter
>Reporter: Alireza Fattahi
>Priority: Minor
> Fix For: 2.5.x
>
>
> In a strust2 + Spring 4 project
> Consider a simple action with stream result
> {code:title=Bar.java|borderStyle=solid}
> @Action(value = "sample-export",
> results = { @Result(name = "success", type = "stream", params = {
> "inputName", "exportInputStream", "contentType",
> "${exportContentType}; charset=UTF-8", "Content-Disposition",
> "attachment; filename=\"${filename}\"", "contentDisposition",
> "attachment; filename=\"${filename}\"", "bufferSize", "2048" }) })
> public String export() throws ClientException {
> //buildExportInputStream() creates and returns new ByteArrayOutputStream
> by using jasper
> exportInputStream = buildExportInputStream();
> LOG.debug("Exporting to {} file ", getFilename());
> return SUCCESS;
> }
> {code}
> This works fine,
> Now define a bean
> {code:xml}
>
>
>
> {code}
> The export will not work correctly any more, first time you get the
> c:/sample.jks as file and then an error which same stream already closed.
> I have found that the sampleStream will be autowired to
> org.apache.struts2.dispatcher.StreamResult and I see this log:
> {panel:title=LOG|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> DEBUG ort.DefaultListableBeanFactory Returning cached instance of singleton
> bean 'sampleStream'
> DEBUG ort.DefaultListableBeanFactory Autowiring by type from bean name
> 'org.apache.struts2.dispatcher.StreamResult' via constructor to bean named
> 'sampleStream'
> {panel}
> This mistaken autowired is the source of problem ! Is there any workaround.
> And by the way, why the sampleStream is autowired here !
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WW-4559) Define a bean of java.io.FileInputStream in Spring makes the Struts stream result not work
[
https://issues.apache.org/jira/browse/WW-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-4559:
Fix Version/s: (was: 2.3.x)
2.5.x
> Define a bean of java.io.FileInputStream in Spring makes the Struts stream
> result not work
> --
>
> Key: WW-4559
> URL: https://issues.apache.org/jira/browse/WW-4559
> Project: Struts 2
> Issue Type: Bug
> Components: Dispatch Filter
>Reporter: Alireza Fattahi
>Priority: Minor
> Fix For: 2.5.x
>
>
> In a strust2 + Spring 4 project
> Consider a simple action with stream result
> {code:title=Bar.java|borderStyle=solid}
> @Action(value = "sample-export",
> results = { @Result(name = "success", type = "stream", params = {
> "inputName", "exportInputStream", "contentType",
> "${exportContentType}; charset=UTF-8", "Content-Disposition",
> "attachment; filename=\"${filename}\"", "contentDisposition",
> "attachment; filename=\"${filename}\"", "bufferSize", "2048" }) })
> public String export() throws ClientException {
> //buildExportInputStream() creates and returns new ByteArrayOutputStream
> by using jasper
> exportInputStream = buildExportInputStream();
> LOG.debug("Exporting to {} file ", getFilename());
> return SUCCESS;
> }
> {code}
> This works fine,
> Now define a bean
> {code:xml}
>
>
>
> {code}
> The export will not work correctly any more, first time you get the
> c:/sample.jks as file and then an error which same stream already closed.
> I have found that the sampleStream will be autowired to
> org.apache.struts2.dispatcher.StreamResult and I see this log:
> {panel:title=LOG|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> DEBUG ort.DefaultListableBeanFactory Returning cached instance of singleton
> bean 'sampleStream'
> DEBUG ort.DefaultListableBeanFactory Autowiring by type from bean name
> 'org.apache.struts2.dispatcher.StreamResult' via constructor to bean named
> 'sampleStream'
> {panel}
> This mistaken autowired is the source of problem ! Is there any workaround.
> And by the way, why the sampleStream is autowired here !
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4559) Define a bean of java.io.FileInputStream in Spring makes the Struts stream result not work
[
https://issues.apache.org/jira/browse/WW-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987441#comment-14987441
]
Rene Gielen commented on WW-4559:
-
It looks like your autowiring strategy is set to "type". See
https://struts.apache.org/docs/spring-plugin.html#Autowiring
Please try to set your strategy explicitly to "name" or "no" and check again.
> Define a bean of java.io.FileInputStream in Spring makes the Struts stream
> result not work
> --
>
> Key: WW-4559
> URL: https://issues.apache.org/jira/browse/WW-4559
> Project: Struts 2
> Issue Type: Bug
> Components: Dispatch Filter
>Reporter: Alireza Fattahi
> Fix For: 2.3.x
>
>
> In a strust2 + Spring 4 project
> Consider a simple action with stream result
> {code:title=Bar.java|borderStyle=solid}
> @Action(value = "sample-export",
> results = { @Result(name = "success", type = "stream", params = {
> "inputName", "exportInputStream", "contentType",
> "${exportContentType}; charset=UTF-8", "Content-Disposition",
> "attachment; filename=\"${filename}\"", "contentDisposition",
> "attachment; filename=\"${filename}\"", "bufferSize", "2048" }) })
> public String export() throws ClientException {
> //buildExportInputStream() creates and returns new ByteArrayOutputStream
> by using jasper
> exportInputStream = buildExportInputStream();
> LOG.debug("Exporting to {} file ", getFilename());
> return SUCCESS;
> }
> {code}
> This works fine,
> Now define a bean
> {code:xml}
>
>
>
> {code}
> The export will not work correctly any more, first time you get the
> c:/sample.jks as file and then an error which same stream already closed.
> I have found that the sampleStream will be autowired to
> org.apache.struts2.dispatcher.StreamResult and I see this log:
> {panel:title=LOG|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> DEBUG ort.DefaultListableBeanFactory Returning cached instance of singleton
> bean 'sampleStream'
> DEBUG ort.DefaultListableBeanFactory Autowiring by type from bean name
> 'org.apache.struts2.dispatcher.StreamResult' via constructor to bean named
> 'sampleStream'
> {panel}
> This mistaken autowired is the source of problem ! Is there any workaround.
> And by the way, why the sampleStream is autowired here !
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4188) In struts tag lib, required attribute removed in latest version ie 2.3.15.1
[
https://issues.apache.org/jira/browse/WW-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201838#comment-14201838
]
Rene Gielen commented on WW-4188:
-
Once in a while I came to feel that we are doing something wrong with adding
the * within the template. That given, how about reverting to a solely CSS
driven solution with the semantics of HTML5 required attribute?
So setting tag attribute {code}required=true{code} would render as
{code}
label class=requiredLabel.../labelinput class=requiredField
required=required ... /
{code}
Obviously, {code}required=required{code} would be completely omitted if the
tag attribute is false.
For backward compatibility, we could recommend the following solution in our
default css to add the * suffix behaviour:
http://stackoverflow.com/questions/2741312/using-css-to-insert-text
In struts tag lib, required attribute removed in latest version ie 2.3.15.1
---
Key: WW-4188
URL: https://issues.apache.org/jira/browse/WW-4188
Project: Struts 2
Issue Type: Bug
Components: Other
Affects Versions: 2.3.15.1
Environment: All
Reporter: mahendran
Assignee: Lukasz Lenart
Labels: struts-tags-required-attribute
Fix For: 2.5
we are using struts 2.0.5 and 2.3.4.1 in our applications. And we decided to
migrate to 2.3.15.1 to get the security fixes.
we use struts tags to render UI components and using 'required' attribute to
get the '*' along with the components.
In the version 2.3.15.1, the attribute required is dropped, and we need to
change to requiredLabel to get the same effect, this increases
migrationtesting effort for a application which has 1000+pages
Hence we require a backward compatibility for 'required' attribute in struts
tags.
Also nowhere in the migration document this information is specified. This
makes the struts migration as block-box. Hence we require a proper migration
document which should specify what are all the changes required in the
application to migrate the struts.
But we managed to get the '*' in UI by replacing
UIBean.class,AbsctactUITag.class and struts.tld from 2.3.4.1 version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4188) In struts tag lib, required attribute removed in latest version ie 2.3.15.1
[ https://issues.apache.org/jira/browse/WW-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201847#comment-14201847 ] Rene Gielen commented on WW-4188: - [~mahendranmahesh] Thanks for your report and your suggestions. To clarify, please be aware that when skipping multiple releases for upgrading, you will have to follow the version and migration notes for each intermediate release up to your target version. Please also understand that this is public benefit Open Source with volunteers working for free on the project. There is nothing like requiring to have them change something. This is an option you might get from a commercial product with paid SLAs, though even this is usually not guaranteed. In turn, our volunteers are always open to users humbly asking for a change - something you might not get from every commercial product :) In struts tag lib, required attribute removed in latest version ie 2.3.15.1 --- Key: WW-4188 URL: https://issues.apache.org/jira/browse/WW-4188 Project: Struts 2 Issue Type: Bug Components: Other Affects Versions: 2.3.15.1 Environment: All Reporter: mahendran Assignee: Lukasz Lenart Labels: struts-tags-required-attribute Fix For: 2.5 we are using struts 2.0.5 and 2.3.4.1 in our applications. And we decided to migrate to 2.3.15.1 to get the security fixes. we use struts tags to render UI components and using 'required' attribute to get the '*' along with the components. In the version 2.3.15.1, the attribute required is dropped, and we need to change to requiredLabel to get the same effect, this increases migrationtesting effort for a application which has 1000+pages Hence we require a backward compatibility for 'required' attribute in struts tags. Also nowhere in the migration document this information is specified. This makes the struts migration as block-box. Hence we require a proper migration document which should specify what are all the changes required in the application to migrate the struts. But we managed to get the '*' in UI by replacing UIBean.class,AbsctactUITag.class and struts.tld from 2.3.4.1 version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (WW-4188) In struts tag lib, required attribute removed in latest version ie 2.3.15.1
[
https://issues.apache.org/jira/browse/WW-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201838#comment-14201838
]
Rene Gielen edited comment on WW-4188 at 11/7/14 9:45 AM:
--
Once in a while I came to feel that we are doing something wrong with adding
the * within the template. That given, how about reverting to a solely CSS
driven solution with the semantics of HTML5 required attribute?
So setting tag attribute {code}required=true{code} would render as
{code}
label class=requiredLabel.../labelinput class=requiredField
required=required ... /
{code}
Obviously, {code}required=required{code} would be completely omitted if the
tag attribute is false.
For backward compatibility, we could recommend the following css based solution
to re-gain the * suffix behaviour:
http://stackoverflow.com/questions/2741312/using-css-to-insert-text
was (Author: rgielen):
Once in a while I came to feel that we are doing something wrong with adding
the * within the template. That given, how about reverting to a solely CSS
driven solution with the semantics of HTML5 required attribute?
So setting tag attribute {code}required=true{code} would render as
{code}
label class=requiredLabel.../labelinput class=requiredField
required=required ... /
{code}
Obviously, {code}required=required{code} would be completely omitted if the
tag attribute is false.
For backward compatibility, we could recommend the following solution in our
default css to add the * suffix behaviour:
http://stackoverflow.com/questions/2741312/using-css-to-insert-text
In struts tag lib, required attribute removed in latest version ie 2.3.15.1
---
Key: WW-4188
URL: https://issues.apache.org/jira/browse/WW-4188
Project: Struts 2
Issue Type: Bug
Components: Other
Affects Versions: 2.3.15.1
Environment: All
Reporter: mahendran
Assignee: Lukasz Lenart
Labels: struts-tags-required-attribute
Fix For: 2.5
we are using struts 2.0.5 and 2.3.4.1 in our applications. And we decided to
migrate to 2.3.15.1 to get the security fixes.
we use struts tags to render UI components and using 'required' attribute to
get the '*' along with the components.
In the version 2.3.15.1, the attribute required is dropped, and we need to
change to requiredLabel to get the same effect, this increases
migrationtesting effort for a application which has 1000+pages
Hence we require a backward compatibility for 'required' attribute in struts
tags.
Also nowhere in the migration document this information is specified. This
makes the struts migration as block-box. Hence we require a proper migration
document which should specify what are all the changes required in the
application to migrate the struts.
But we managed to get the '*' in UI by replacing
UIBean.class,AbsctactUITag.class and struts.tld from 2.3.4.1 version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4188) In struts tag lib, required attribute removed in latest version ie 2.3.15.1
[ https://issues.apache.org/jira/browse/WW-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201874#comment-14201874 ] Rene Gielen commented on WW-4188: - [~cn42] There might be issues, yes - but this actually CSS2, not even CSS3. We should really think of not staying backwards compatible to ancient browsers at all costs. Additionally, users would be able to override the default template with the theme mechanism if they feel they need to support IE6 or similar zombies... In struts tag lib, required attribute removed in latest version ie 2.3.15.1 --- Key: WW-4188 URL: https://issues.apache.org/jira/browse/WW-4188 Project: Struts 2 Issue Type: Bug Components: Other Affects Versions: 2.3.15.1 Environment: All Reporter: mahendran Assignee: Lukasz Lenart Labels: struts-tags-required-attribute Fix For: 2.5 we are using struts 2.0.5 and 2.3.4.1 in our applications. And we decided to migrate to 2.3.15.1 to get the security fixes. we use struts tags to render UI components and using 'required' attribute to get the '*' along with the components. In the version 2.3.15.1, the attribute required is dropped, and we need to change to requiredLabel to get the same effect, this increases migrationtesting effort for a application which has 1000+pages Hence we require a backward compatibility for 'required' attribute in struts tags. Also nowhere in the migration document this information is specified. This makes the struts migration as block-box. Hence we require a proper migration document which should specify what are all the changes required in the application to migrate the struts. But we managed to get the '*' in UI by replacing UIBean.class,AbsctactUITag.class and struts.tld from 2.3.4.1 version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WW-4402) JDK 8: build fails due to missing apt tool
Rene Gielen created WW-4402: --- Summary: JDK 8: build fails due to missing apt tool Key: WW-4402 URL: https://issues.apache.org/jira/browse/WW-4402 Project: Struts 2 Issue Type: Bug Components: Build Management Affects Versions: 2.3.16.3 Environment: JDK 8 Reporter: Rene Gielen Fix For: 2.5 The generation of Struts Taglib TLD files relies on annotation processing with the apt tool, wrapped by maven-apt-plugin. In JDK 7 apt has been [deprecated|http://docs.oracle.com/javase/7/docs/technotes/guides/apt/GettingStarted.html] in favor of [JSR 269|https://jcp.org/en/jsr/detail?id=269]. In JDK 8 apt tool has been [removed completely|http://openjdk.java.net/jeps/117]. In effect, Struts core and all tag library projects relying on the struts-annotation helper library won't build any longer under JDK 8. A major effort is needed to introduce a compatible replacement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WW-4403) JDK 8: build fails due to JavaDoc checking issues
Rene Gielen created WW-4403:
---
Summary: JDK 8: build fails due to JavaDoc checking issues
Key: WW-4403
URL: https://issues.apache.org/jira/browse/WW-4403
Project: Struts 2
Issue Type: Bug
Components: Build Management
Affects Versions: 2.3.16.3
Reporter: Rene Gielen
Fix For: 2.5
JDK 8 introduced stricter checking for JavaDoc processing, causing issues
formerly producing warning messages to break the build.
Basically the fix is as easy as adding the following configuration to the
pluginManagement section:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.9.1/version
configuration
showprivate/show
additionalparam-Xdoclint:none/additionalparam
/configuration
/plugin
{code}
To fix and close this issue, we need a testable build though which is curretnly
blocked by WW-4402
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WW-4403) JDK 8: build fails due to JavaDoc checking issues
[
https://issues.apache.org/jira/browse/WW-4403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-4403:
Description:
JDK 8 introduced stricter checking for JavaDoc processing, causing issues
formerly producing warning messages to break the build.
Basically the fix is as easy as adding the following configuration to the
pluginManagement section:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.9.1/version
configuration
showprivate/show
additionalparam-Xdoclint:none/additionalparam
/configuration
/plugin
{code}
To fix and close this issue, we need a testable build though which is currently
blocked by WW-4402
was:
JDK 8 introduced stricter checking for JavaDoc processing, causing issues
formerly producing warning messages to break the build.
Basically the fix is as easy as adding the following configuration to the
pluginManagement section:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.9.1/version
configuration
showprivate/show
additionalparam-Xdoclint:none/additionalparam
/configuration
/plugin
{code}
To fix and close this issue, we need a testable build though which is curretnly
blocked by WW-4402
JDK 8: build fails due to JavaDoc checking issues
-
Key: WW-4403
URL: https://issues.apache.org/jira/browse/WW-4403
Project: Struts 2
Issue Type: Bug
Components: Build Management
Affects Versions: 2.3.16.3
Reporter: Rene Gielen
Labels: jdk8
Fix For: 2.5
JDK 8 introduced stricter checking for JavaDoc processing, causing issues
formerly producing warning messages to break the build.
Basically the fix is as easy as adding the following configuration to the
pluginManagement section:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.9.1/version
configuration
showprivate/show
additionalparam-Xdoclint:none/additionalparam
/configuration
/plugin
{code}
To fix and close this issue, we need a testable build though which is
currently blocked by WW-4402
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4403) JDK 8: build fails due to JavaDoc checking issues
[
https://issues.apache.org/jira/browse/WW-4403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131215#comment-14131215
]
Rene Gielen commented on WW-4403:
-
Testability is blocked by fixing this blocking build issue
JDK 8: build fails due to JavaDoc checking issues
-
Key: WW-4403
URL: https://issues.apache.org/jira/browse/WW-4403
Project: Struts 2
Issue Type: Bug
Components: Build Management
Affects Versions: 2.3.16.3
Reporter: Rene Gielen
Labels: jdk8
Fix For: 2.5
JDK 8 introduced stricter checking for JavaDoc processing, causing issues
formerly producing warning messages to break the build.
Basically the fix is as easy as adding the following configuration to the
pluginManagement section:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.9.1/version
configuration
showprivate/show
additionalparam-Xdoclint:none/additionalparam
/configuration
/plugin
{code}
To fix and close this issue, we need a testable build though which is
currently blocked by WW-4402
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WW-4347) Support for JDK 8
[
https://issues.apache.org/jira/browse/WW-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-4347:
Labels: jdk8 (was: )
Support for JDK 8
-
Key: WW-4347
URL: https://issues.apache.org/jira/browse/WW-4347
Project: Struts 2
Issue Type: New Feature
Components: Core Actions
Affects Versions: 2.3.16.3
Reporter: Erik Berg
Labels: jdk8
Fix For: 2.3.18
Attachments: jdk8test.tar
Struts stumbles when encountering lambda expressions in JDK 8. Looks like
org.objwectweb.asm dependency needs to be updated...
{code}
2014-05-18 10:21:41,111 ERROR
(com.opensymphony.xwork2.util.finder.ClassFinder:38) - Unable to read class
[jdk8test.actions.Lambda]
java.lang.ArrayIndexOutOfBoundsException: 52264
at org.objectweb.asm.ClassReader.readClass(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at
com.opensymphony.xwork2.util.finder.ClassFinder.readClassDef(ClassFinder.java:717)
at
com.opensymphony.xwork2.util.finder.ClassFinder.init(ClassFinder.java:112)
at
org.apache.struts2.convention.PackageBasedActionConfigBuilder.findActions(PackageBasedActionConfigBuilder.java:390)
at
org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildActionConfigs(PackageBasedActionConfigBuilder.java:347)
at
org.apache.struts2.convention.ClasspathPackageProvider.loadPackages(ClasspathPackageProvider.java:53)
at
com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:268)
at
com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:67)
at
org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:445)
at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:489)
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.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:281)
at
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:262)
at
org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:107)
at
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4775)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5452)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
{code}
Simple test case attached.
tar xvf jdk8test.tar
cd jdk8test
mvn tomcat7:run
http://localhost:8080/jdk8test
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (WW-4347) Support for JDK 8 Lambdas
[
https://issues.apache.org/jira/browse/WW-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-4347:
Summary: Support for JDK 8 Lambdas (was: Support for JDK 8)
Support for JDK 8 Lambdas
-
Key: WW-4347
URL: https://issues.apache.org/jira/browse/WW-4347
Project: Struts 2
Issue Type: New Feature
Components: Core Actions
Affects Versions: 2.3.16.3
Reporter: Erik Berg
Labels: jdk8
Fix For: 2.3.18
Attachments: jdk8test.tar
Struts stumbles when encountering lambda expressions in JDK 8. Looks like
org.objwectweb.asm dependency needs to be updated...
{code}
2014-05-18 10:21:41,111 ERROR
(com.opensymphony.xwork2.util.finder.ClassFinder:38) - Unable to read class
[jdk8test.actions.Lambda]
java.lang.ArrayIndexOutOfBoundsException: 52264
at org.objectweb.asm.ClassReader.readClass(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at
com.opensymphony.xwork2.util.finder.ClassFinder.readClassDef(ClassFinder.java:717)
at
com.opensymphony.xwork2.util.finder.ClassFinder.init(ClassFinder.java:112)
at
org.apache.struts2.convention.PackageBasedActionConfigBuilder.findActions(PackageBasedActionConfigBuilder.java:390)
at
org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildActionConfigs(PackageBasedActionConfigBuilder.java:347)
at
org.apache.struts2.convention.ClasspathPackageProvider.loadPackages(ClasspathPackageProvider.java:53)
at
com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:268)
at
com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:67)
at
org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:445)
at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:489)
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.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:281)
at
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:262)
at
org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:107)
at
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4775)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5452)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
{code}
Simple test case attached.
tar xvf jdk8test.tar
cd jdk8test
mvn tomcat7:run
http://localhost:8080/jdk8test
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-3113) Struts 2 and Flat Tire in my car
[ https://issues.apache.org/jira/browse/WW-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14112707#comment-14112707 ] Rene Gielen commented on WW-3113: - [~musachy] Thanks for your input regarding SLAs. As you most probably might know, Struts 2 premium products were always aimed at premium customers willing to pay premium prices. That said, at a special Old-friends-and-valued-partner discount of only €999 (daily subscription price) I'd offer you premium 24/7 call-me-I'll-come-to-rescue support (may take some time though, have to book flights first). That said, you should be aware that we have noticed some long-run issues with the JSP-TAG Exhaust Components you were involved with regarding engineering. If you'd be willing to help fixing these issues, I'd lower last offer to ... not 10 ... not 20 ... not 30 ... no - 50% off! I must be crazy!!! Get it while it's hot! Struts 2 and Flat Tire in my car Key: WW-3113 URL: https://issues.apache.org/jira/browse/WW-3113 Project: Struts 2 Issue Type: Bug Affects Versions: 2.1.6 Reporter: musachy Priority: Critical Fix For: Future Attachments: abstract-tire-factory.jpg, patch4.jpg, tire-plug[in].jpg, workaround_attempt.jpg I used Struts 2 today and now I have a flat tire in my car, so it must be somehow related. Please fix it ASAP because I need to drive home today. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (WW-3113) Struts 2 and Flat Tire in my car
[ https://issues.apache.org/jira/browse/WW-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14112717#comment-14112717 ] Rene Gielen commented on WW-3113: - [~newton_dave] I fear this is not enterprisy enough for our needs - c'mon, we're EE - Jayyy EE ! Although I haven't got a descriptive photo at hand right now, we should consider an abstract Factory creating concrete factories for concrete implementations of abstract interfaces describing abstract strategies guarded by powerful observers. Struts 2 and Flat Tire in my car Key: WW-3113 URL: https://issues.apache.org/jira/browse/WW-3113 Project: Struts 2 Issue Type: Bug Affects Versions: 2.1.6 Reporter: musachy Priority: Critical Fix For: Future Attachments: abstract-tire-factory.jpg, patch4.jpg, tire-plug[in].jpg, workaround_attempt.jpg I used Struts 2 today and now I have a flat tire in my car, so it must be somehow related. Please fix it ASAP because I need to drive home today. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (WW-3113) Struts 2 and Flat Tire in my car
[ https://issues.apache.org/jira/browse/WW-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14112707#comment-14112707 ] Rene Gielen edited comment on WW-3113 at 8/27/14 8:45 PM: -- [~musachy] Thanks for your input regarding SLAs. As you most probably might know, Struts 2 premium products were always aimed at premium customers willing to pay premium prices. That said, at a special Old-friends-and-valued-partner discount of only €999 (daily subscription price) I'd offer you premium 24/7 call-me-I'll-come-to-rescue support (may take some time though, have to book flights first). That said, you should be aware that we have noticed some long-run issues with the JAVA-TAG Lava-Proof Exhaust Components you were involved with regarding engineering. If you'd be willing to help fixing these issues, I'd lower last offer to ... not 10 ... not 20 ... not 30 ... no - 50% off! I must be crazy!!! Get it while it's hot! was (Author: rgielen): [~musachy] Thanks for your input regarding SLAs. As you most probably might know, Struts 2 premium products were always aimed at premium customers willing to pay premium prices. That said, at a special Old-friends-and-valued-partner discount of only €999 (daily subscription price) I'd offer you premium 24/7 call-me-I'll-come-to-rescue support (may take some time though, have to book flights first). That said, you should be aware that we have noticed some long-run issues with the JSP-TAG Exhaust Components you were involved with regarding engineering. If you'd be willing to help fixing these issues, I'd lower last offer to ... not 10 ... not 20 ... not 30 ... no - 50% off! I must be crazy!!! Get it while it's hot! Struts 2 and Flat Tire in my car Key: WW-3113 URL: https://issues.apache.org/jira/browse/WW-3113 Project: Struts 2 Issue Type: Bug Affects Versions: 2.1.6 Reporter: musachy Priority: Critical Fix For: Future Attachments: abstract-tire-factory.jpg, patch4.jpg, tire-plug[in].jpg, workaround_attempt.jpg I used Struts 2 today and now I have a flat tire in my car, so it must be somehow related. Please fix it ASAP because I need to drive home today. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (WW-4347) Support for JDK 8
[
https://issues.apache.org/jira/browse/WW-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14095496#comment-14095496
]
Rene Gielen commented on WW-4347:
-
Java 8 byte code is officially supported since ASM 5. XWork, however, still
uses ASM 3.3
Unfortunately ASM 5 is not a drop-in replacement.
I've stumbled upon the following question on SO:
http://stackoverflow.com/questions/24455349/make-struts-2-compatible-with-java-8-legacy-asm-3
The author answers his own question by stating he had to patch XWork. He
created the following patch:
https://gist.github.com/anonymous/017b23c1d7c97c37d167
We should review the patch and check for downward compatibility. If it renders
OK, we should switch to ASM 5 with XWork patch included.
Support for JDK 8
-
Key: WW-4347
URL: https://issues.apache.org/jira/browse/WW-4347
Project: Struts 2
Issue Type: New Feature
Components: Core Actions
Affects Versions: 2.3.16.3
Reporter: Erik Berg
Fix For: 2.5
Attachments: jdk8test.tar
Struts stumbles when encountering lambda expressions in JDK 8. Looks like
org.objwectweb.asm dependency needs to be updated...
{code}
2014-05-18 10:21:41,111 ERROR
(com.opensymphony.xwork2.util.finder.ClassFinder:38) - Unable to read class
[jdk8test.actions.Lambda]
java.lang.ArrayIndexOutOfBoundsException: 52264
at org.objectweb.asm.ClassReader.readClass(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at
com.opensymphony.xwork2.util.finder.ClassFinder.readClassDef(ClassFinder.java:717)
at
com.opensymphony.xwork2.util.finder.ClassFinder.init(ClassFinder.java:112)
at
org.apache.struts2.convention.PackageBasedActionConfigBuilder.findActions(PackageBasedActionConfigBuilder.java:390)
at
org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildActionConfigs(PackageBasedActionConfigBuilder.java:347)
at
org.apache.struts2.convention.ClasspathPackageProvider.loadPackages(ClasspathPackageProvider.java:53)
at
com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:268)
at
com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:67)
at
org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:445)
at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:489)
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.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:281)
at
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:262)
at
org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:107)
at
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4775)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5452)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
{code}
Simple test case attached.
tar xvf jdk8test.tar
cd jdk8test
mvn tomcat7:run
http://localhost:8080/jdk8test
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (WW-4347) Support for JDK 8
[
https://issues.apache.org/jira/browse/WW-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-4347:
Fix Version/s: (was: 2.5)
2.3.18
Support for JDK 8
-
Key: WW-4347
URL: https://issues.apache.org/jira/browse/WW-4347
Project: Struts 2
Issue Type: New Feature
Components: Core Actions
Affects Versions: 2.3.16.3
Reporter: Erik Berg
Fix For: 2.3.18
Attachments: jdk8test.tar
Struts stumbles when encountering lambda expressions in JDK 8. Looks like
org.objwectweb.asm dependency needs to be updated...
{code}
2014-05-18 10:21:41,111 ERROR
(com.opensymphony.xwork2.util.finder.ClassFinder:38) - Unable to read class
[jdk8test.actions.Lambda]
java.lang.ArrayIndexOutOfBoundsException: 52264
at org.objectweb.asm.ClassReader.readClass(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at
com.opensymphony.xwork2.util.finder.ClassFinder.readClassDef(ClassFinder.java:717)
at
com.opensymphony.xwork2.util.finder.ClassFinder.init(ClassFinder.java:112)
at
org.apache.struts2.convention.PackageBasedActionConfigBuilder.findActions(PackageBasedActionConfigBuilder.java:390)
at
org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildActionConfigs(PackageBasedActionConfigBuilder.java:347)
at
org.apache.struts2.convention.ClasspathPackageProvider.loadPackages(ClasspathPackageProvider.java:53)
at
com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:268)
at
com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:67)
at
org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:445)
at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:489)
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.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:281)
at
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:262)
at
org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:107)
at
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4775)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5452)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
{code}
Simple test case attached.
tar xvf jdk8test.tar
cd jdk8test
mvn tomcat7:run
http://localhost:8080/jdk8test
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (WW-4347) Support for JDK 8
[
https://issues.apache.org/jira/browse/WW-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14095551#comment-14095551
]
Rene Gielen commented on WW-4347:
-
As suggested by [~lukaszlenart], I've moved this issue to 2.3.18 fix target for
now. Should be revisited if we get problems holding up a release.
Support for JDK 8
-
Key: WW-4347
URL: https://issues.apache.org/jira/browse/WW-4347
Project: Struts 2
Issue Type: New Feature
Components: Core Actions
Affects Versions: 2.3.16.3
Reporter: Erik Berg
Fix For: 2.3.18
Attachments: jdk8test.tar
Struts stumbles when encountering lambda expressions in JDK 8. Looks like
org.objwectweb.asm dependency needs to be updated...
{code}
2014-05-18 10:21:41,111 ERROR
(com.opensymphony.xwork2.util.finder.ClassFinder:38) - Unable to read class
[jdk8test.actions.Lambda]
java.lang.ArrayIndexOutOfBoundsException: 52264
at org.objectweb.asm.ClassReader.readClass(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at
com.opensymphony.xwork2.util.finder.ClassFinder.readClassDef(ClassFinder.java:717)
at
com.opensymphony.xwork2.util.finder.ClassFinder.init(ClassFinder.java:112)
at
org.apache.struts2.convention.PackageBasedActionConfigBuilder.findActions(PackageBasedActionConfigBuilder.java:390)
at
org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildActionConfigs(PackageBasedActionConfigBuilder.java:347)
at
org.apache.struts2.convention.ClasspathPackageProvider.loadPackages(ClasspathPackageProvider.java:53)
at
com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:268)
at
com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:67)
at
org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:445)
at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:489)
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.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:281)
at
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:262)
at
org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:107)
at
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4775)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5452)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
{code}
Simple test case attached.
tar xvf jdk8test.tar
cd jdk8test
mvn tomcat7:run
http://localhost:8080/jdk8test
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (WW-4207) Upgrade to OGNL 3.0.8
[
https://issues.apache.org/jira/browse/WW-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966483#comment-13966483
]
Rene Gielen commented on WW-4207:
-
I make a case for upgrading to OGNL 3.0.9, for which I hope the following
change will be applied :)
- Upgrade javassist dependency to 3.1.18
The reason is that this version is not only compatible with Hibernate 4, but
also with JDK8. Incompatibility with Hibernate 4 is due to the fact that
javassisst groupId unfortunately changed from javassist to org.javassist. Thus
you get two javassist jar in your built artifact. Currently, to work with
Hibernate and other tools introducing transiteve dependencies to newer
javassist coordinates and versions, one has to exclude old dependency from
struts-core:
{code:xml}
dependency
groupIdorg.apache.struts/groupId
artifactIdstruts2-core/artifactId
version${struts2.version}/version
exclusions
exclusion
groupIdjavassist/groupId
artifactIdjavassist/artifactId
/exclusion
/exclusions
/dependency
{code}
Should I raise an issue for OGNL, and if yes, where?
Upgrade to OGNL 3.0.8
-
Key: WW-4207
URL: https://issues.apache.org/jira/browse/WW-4207
Project: Struts 2
Issue Type: Improvement
Components: Value Stack
Affects Versions: 2.3.15
Reporter: Lukasz Lenart
Assignee: Lukasz Lenart
Fix For: 2.5
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (WW-4207) Upgrade to OGNL 3.0.8
[
https://issues.apache.org/jira/browse/WW-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966483#comment-13966483
]
Rene Gielen edited comment on WW-4207 at 4/11/14 1:35 PM:
--
I make a case for upgrading to OGNL 3.0.9, for which I hope the following
change will be applied :)
- Upgrade javassist dependency to 3.1.18
The reason is that current version is not only incompatible with Hibernate 4,
but also with JDK8. Incompatibility with Hibernate 4 is due to the fact that
javassisst groupId unfortunately changed from javassist to org.javassist. Thus
you get two javassist jar in your built artifact. Currently, to incorporate
Hibernate and other libraries introducing transitive dependencies to newer
javassist coordinates and versions, one has to exclude old dependency from
struts-core:
{code:xml}
dependency
groupIdorg.apache.struts/groupId
artifactIdstruts2-core/artifactId
version${struts2.version}/version
exclusions
exclusion
groupIdjavassist/groupId
artifactIdjavassist/artifactId
/exclusion
/exclusions
/dependency
{code}
Should I raise an issue for OGNL, and if yes, where?
was (Author: rgielen):
I make a case for upgrading to OGNL 3.0.9, for which I hope the following
change will be applied :)
- Upgrade javassist dependency to 3.1.18
The reason is that this version is not only compatible with Hibernate 4, but
also with JDK8. Incompatibility with Hibernate 4 is due to the fact that
javassisst groupId unfortunately changed from javassist to org.javassist. Thus
you get two javassist jar in your built artifact. Currently, to work with
Hibernate and other tools introducing transiteve dependencies to newer
javassist coordinates and versions, one has to exclude old dependency from
struts-core:
{code:xml}
dependency
groupIdorg.apache.struts/groupId
artifactIdstruts2-core/artifactId
version${struts2.version}/version
exclusions
exclusion
groupIdjavassist/groupId
artifactIdjavassist/artifactId
/exclusion
/exclusions
/dependency
{code}
Should I raise an issue for OGNL, and if yes, where?
Upgrade to OGNL 3.0.8
-
Key: WW-4207
URL: https://issues.apache.org/jira/browse/WW-4207
Project: Struts 2
Issue Type: Improvement
Components: Value Stack
Affects Versions: 2.3.15
Reporter: Lukasz Lenart
Assignee: Lukasz Lenart
Fix For: 2.5
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (WW-3952) creditCard validator available in Struts 1 missing in Struts 2
[ https://issues.apache.org/jira/browse/WW-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966489#comment-13966489 ] Rene Gielen commented on WW-3952: - [~dleberre] When doing feature requests, patches are always welcome :) creditCard validator available in Struts 1 missing in Struts 2 -- Key: WW-3952 URL: https://issues.apache.org/jira/browse/WW-3952 Project: Struts 2 Issue Type: Improvement Components: XML Validators Affects Versions: 2.3.8 Reporter: Daniel Le Berre Fix For: 2.3.18 Struts 1 has a creditCard validator. That validator does not exists in Struts 2. It would be nice to have also that validator in Struts 2 to allow an easier migration from Struts 1 to Struts 2. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (WW-3952) creditCard validator available in Struts 1 missing in Struts 2
[ https://issues.apache.org/jira/browse/WW-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13966524#comment-13966524 ] Rene Gielen commented on WW-3952: - Two nice ideas coming to my mind: - show your students how to use RegExp validations, taking credit card number as example - show your students how to implement custom validators, which is fairly easy :) Re-applying the Struts 1 solution has the downside of introducing a fairly heavy new dependency (commons-validator). On the other hand, maybe some people find it useful to create an externally hosted Struts2 plugin for bridging commons-validator... creditCard validator available in Struts 1 missing in Struts 2 -- Key: WW-3952 URL: https://issues.apache.org/jira/browse/WW-3952 Project: Struts 2 Issue Type: Improvement Components: XML Validators Affects Versions: 2.3.8 Reporter: Daniel Le Berre Fix For: 2.3.18 Struts 1 has a creditCard validator. That validator does not exists in Struts 2. It would be nice to have also that validator in Struts 2 to allow an easier migration from Struts 1 to Struts 2. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (WW-4088) Supressing empty parameters on s:a tag
[
https://issues.apache.org/jira/browse/WW-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862600#comment-13862600
]
Rene Gielen commented on WW-4088:
-
Greg, thanks for the patch. I haven't yet reviewed it, but I have another
question: mid November I reached out to you on behalf of the Struts PMC via the
email address provided in your JIRA user profile. Since we did not hear back
from you, I am afraid our mail did not reach you. Could you please contact me?
rgielen at apache dot org.
Thanks in advance
Supressing empty parameters on s:a tag
-
Key: WW-4088
URL: https://issues.apache.org/jira/browse/WW-4088
Project: Struts 2
Issue Type: Improvement
Components: Plugin - Java Templates, Plugin - Tags
Affects Versions: 2.3.14.2
Environment: Tomcat/Centos
Reporter: Greg Huber
Assignee: Lukasz Lenart
Priority: Minor
Fix For: 2.3.16
Attachments: paramtag_patch.txt, patch.txt, patch.txt
Hello,
When using the s:a anchor tag you can get parameters with empty values ie
?foo= for null values.
It would be good if there was a way to filter these out, similar to the
struts.xml param name=suppressEmptyParameterstrue/param. The s:if
tags in the body are ignored. I either have to do it in programatically or
use jstl :(
ie possibly do something similar :
from:
{code:xml}
s:a action=eventAdd accesskey=a
s:text name=title.heading.eventadd /
c:if test=${not empty bean.searchString}
s:param name=bean.searchString value=%{bean.searchString} /
/c:if
c:if test=${not empty bean.filter}
s:param name=bean.filter value=%{bean.filter} /
/c:if
s:param name=bean.pageNum value=%{pager.pageNumber} /
/s:a
{code}
To:
{code:xml}
s:a action=eventAdd accesskey=a
s:text name=title.heading.eventadd /
s:param name=bean.searchString value=%{bean.searchString} /
s:param name=bean.filter value=%{bean.filter} /
s:param name=bean.pageNum value=%{pager.pageNumber} /
s:param name=suppressEmptyParameters value=true/
/s:a
{code}
(Ref WW-3920)
Cheers Greg
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (WW-4221) Performance issue in Java Web Deployment in Cloud Computing
[ https://issues.apache.org/jira/browse/WW-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen updated WW-4221: Labels: (was: patch) Performance issue in Java Web Deployment in Cloud Computing --- Key: WW-4221 URL: https://issues.apache.org/jira/browse/WW-4221 Project: Struts 2 Issue Type: New Feature Components: New API Affects Versions: 2.3.8 Environment: Cloud Platforms, Java Reporter: Ankit Kumar Sahu Fix For: 2.3.8 Original Estimate: 168h Remaining Estimate: 168h Cloud Computing is a coming technology. Spring Framework has been customized for the Cloud Deployment of Java. But Struts have not customized its framework for cloud deployment yet now. Why So? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (WW-4221) Performance issue in Java Web Deployment in Cloud Computing
[ https://issues.apache.org/jira/browse/WW-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen updated WW-4221: Flags: (was: Patch) Performance issue in Java Web Deployment in Cloud Computing --- Key: WW-4221 URL: https://issues.apache.org/jira/browse/WW-4221 Project: Struts 2 Issue Type: New Feature Components: New API Affects Versions: 2.3.8 Environment: Cloud Platforms, Java Reporter: Ankit Kumar Sahu Fix For: 2.3.8 Original Estimate: 168h Remaining Estimate: 168h Cloud Computing is a coming technology. Spring Framework has been customized for the Cloud Deployment of Java. But Struts have not customized its framework for cloud deployment yet now. Why So? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (WW-4221) Performance issue in Java Web Deployment in Cloud Computing
[ https://issues.apache.org/jira/browse/WW-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen resolved WW-4221. - Resolution: Invalid Fix Version/s: (was: 2.3.8) Assignee: Rene Gielen This is not an issue, this is a question. Please use the mailing lists to ask questions and start questions both with Struts users and developers. See http://struts.apache.org/mail.html and http://struts.apache.org/dev/dev-mail.html for details. In direct reply to your question: The answer to any why does Struts not have feature x-question is most likely because no one stepped up to add this feature. It could be you to step up - we always welcome patches, you don't have to be a Struts committer to get your code / solution into one of the next releases. As long as it solves a general issue and code and test code quality is reasonable, a patch is most likely to be accepted. This is also the way where committership starts - people who submit patches and engage in the community over some time are asked at some point if they want to become committers. Regarding your cloud computing feature request, what is it what you are missing? Try to start a discussion on the mailing list, pointing out what you are missing / how possible features could look like concretely. Others may chime in and add their point of view. Be aware that cloud computing is a label / marketing term in the first place. User stories would be a good place to start describing possible new features and have productive discussions. Performance issue in Java Web Deployment in Cloud Computing --- Key: WW-4221 URL: https://issues.apache.org/jira/browse/WW-4221 Project: Struts 2 Issue Type: New Feature Components: New API Affects Versions: 2.3.8 Environment: Cloud Platforms, Java Reporter: Ankit Kumar Sahu Assignee: Rene Gielen Original Estimate: 168h Remaining Estimate: 168h Cloud Computing is a coming technology. Spring Framework has been customized for the Cloud Deployment of Java. But Struts have not customized its framework for cloud deployment yet now. Why So? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (WW-4221) Performance issue in Java Web Deployment in Cloud Computing
[ https://issues.apache.org/jira/browse/WW-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794418#comment-13794418 ] Rene Gielen edited comment on WW-4221 at 10/14/13 8:14 PM: --- This is not an issue, this is a question. Please use the mailing lists to ask questions and start discussions both with Struts users and developers. See http://struts.apache.org/mail.html and http://struts.apache.org/dev/dev-mail.html for details. In direct reply to your question: The answer to any why does Struts not have feature x-question is most likely because no one stepped up to add this feature. It could be you to step up - we always welcome patches, you don't have to be a Struts committer to get your code / solution into one of the next releases. As long as it solves a general issue and code and test code quality is reasonable, a patch is most likely to be accepted. This is also the way where committership starts - people who submit patches and engage in the community over some time are asked at some point if they want to become committers. Regarding your cloud computing feature request, what is it what you are missing? Try to start a discussion on the mailing list, pointing out what you are missing / how possible features could look like concretely. Others may chime in and add their point of view. Be aware that cloud computing is a label / marketing term in the first place. User stories would be a good place to start describing possible new features and have productive discussions. was (Author: rgielen): This is not an issue, this is a question. Please use the mailing lists to ask questions and start questions both with Struts users and developers. See http://struts.apache.org/mail.html and http://struts.apache.org/dev/dev-mail.html for details. In direct reply to your question: The answer to any why does Struts not have feature x-question is most likely because no one stepped up to add this feature. It could be you to step up - we always welcome patches, you don't have to be a Struts committer to get your code / solution into one of the next releases. As long as it solves a general issue and code and test code quality is reasonable, a patch is most likely to be accepted. This is also the way where committership starts - people who submit patches and engage in the community over some time are asked at some point if they want to become committers. Regarding your cloud computing feature request, what is it what you are missing? Try to start a discussion on the mailing list, pointing out what you are missing / how possible features could look like concretely. Others may chime in and add their point of view. Be aware that cloud computing is a label / marketing term in the first place. User stories would be a good place to start describing possible new features and have productive discussions. Performance issue in Java Web Deployment in Cloud Computing --- Key: WW-4221 URL: https://issues.apache.org/jira/browse/WW-4221 Project: Struts 2 Issue Type: New Feature Components: New API Affects Versions: 2.3.8 Environment: Cloud Platforms, Java Reporter: Ankit Kumar Sahu Assignee: Rene Gielen Original Estimate: 168h Remaining Estimate: 168h Cloud Computing is a coming technology. Spring Framework has been customized for the Cloud Deployment of Java. But Struts have not customized its framework for cloud deployment yet now. Why So? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (WW-4203) Allow disabling xwork creating null objects on a property level
[ https://issues.apache.org/jira/browse/WW-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770492#comment-13770492 ] Rene Gielen commented on WW-4203: - How about developing and sharing a patch for such a feature? 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.1, 2.3.15.2 Reporter: Jasper Rosenberg Priority: Minor Labels: interceptors, typeconverter, xwork Fix For: 2.3.17 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] [Commented] (WW-3651) Struts 2 is calling response.setLocale even though it will not handle the request
[
https://issues.apache.org/jira/browse/WW-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770516#comment-13770516
]
Rene Gielen commented on WW-3651:
-
I thing not calling setLocale has the side effect of, well, not setting the
response locale. It will _only_ have a side effect on encoding if not character
encoding is set so far:
{code}
It also sets the response's character encoding appropriately for the locale, if
the character encoding has not been explicitly set using setContentType or
setCharacterEncoding, getWriter hasn't been called yet, and the response hasn't
been committed yet.
{code}
Setting the locale is really important to our framework users. Serving static
resource with various encodings on the other hand is not the usual 80% use
case. I think you should chose out of these two:
1. use UTF-8 all the way, and set {{struts.i18n.encoding=UTF-8}}. This should
take precedence over the encoding side effect of setLocale - if not, this is a
bug to address.
2. place your custom filter after StrutsPrepareFilter and address the encoding
issues you are facing as you specifically need it
I really recommend option 1, UTF-8 is the only true source nowadays :)
But dropping setLocale is really not what we want.
Struts 2 is calling response.setLocale even though it will not handle the
request
-
Key: WW-3651
URL: https://issues.apache.org/jira/browse/WW-3651
Project: Struts 2
Issue Type: Bug
Components: Dispatch Filter
Affects Versions: 2.2.3
Environment: Windows 7, Java 1.6
Reporter: Alfredo Osorio
Fix For: 2.3.16
The org.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter --
org.apache.struts2.dispatcher.Dispatcher.prepare(HttpServletRequest request,
HttpServletResponse response) is calling response.setLocale(locale) when you
specify a default locale (using struts.properties struts.locale). This is
wrong because consider the following example:
This is a static resource stored in the following path:
www.mydomain.com/myApp/scripts/utils.js where myApp is the webcontext and
/scripts/utils.js is a java script file.
1. A request to /myApp/scripts/utils.js.
1. Even though Struts 2 is not going to handle the request
org.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter calls
prepare.setEncodingAndLocale(request, response);
which sets the Request Encoding and the Response Locale.
2. Servlet Container Response setLocale obtains the character encoding
corresponding to that locale and assign a character encoding to the response.
This behavior is correct according to the spec:
http://download.oracle.com/javaee/5/api/javax/servlet/ServletResponse.html#setLocale%28java.util.Locale%29
3. Struts Execute filter doesn't handle the request so
chain.doFilter(request, response); is called.
4. Once all filters are called the servlet container DefaultServlet is called
to handle the request and send the content of the file assigning the response
header Content-Type in which this case it will use the encoding type that was
set before by the StrutsPrepareFilter. This might not correspond to the
actual encoding of the file.
An example of the Header Response Content-Type:
Content-Type application/x-javascript;charset=ISO-8859-1
This only happens when you specify the default locale in the
struts.properties because of these lines in Dispatcher.prepare():
{code:java}
String encoding = null;
if (defaultEncoding != null) {
encoding = defaultEncoding;
}
Locale locale = null;
if (defaultLocale != null) {
locale = LocalizedTextUtil.localeFromString(defaultLocale,
request.getLocale());
}
{code}
I think that locale = LocalizedTextUtil.localeFromString(defaultLocale,
request.getLocale()); should be removed because setting locale will set the
character encoding. And this has side effects when requests are made to
static resources.
--
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] [Comment Edited] (WW-3651) Struts 2 is calling response.setLocale even though it will not handle the request
[
https://issues.apache.org/jira/browse/WW-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770516#comment-13770516
]
Rene Gielen edited comment on WW-3651 at 9/18/13 6:59 AM:
--
I thing not calling setLocale has the side effect of, well, not setting the
response locale. It will _only_ have a side effect on encoding if not character
encoding is set so far:
{code}
It also sets the response's character encoding appropriately for the locale,
if the character encoding has not been explicitly set using setContentType
or setCharacterEncoding, getWriter hasn't been called yet, and the response
hasn't been committed yet.
{code}
Setting the locale is really important to our framework users. Serving static
resource with various encodings on the other hand is not the usual 80% use
case. I think you should chose out of these two:
1. use UTF-8 all the way, and set {{struts.i18n.encoding=UTF-8}}. This should
take precedence over the encoding side effect of setLocale - if not, this is a
bug to address.
2. place your custom filter after StrutsPrepareFilter and address the encoding
issues you are facing as you specifically need it
I really recommend option 1, UTF-8 is the only true source nowadays :)
But dropping setLocale is really not what we want.
was (Author: rgielen):
I thing not calling setLocale has the side effect of, well, not setting the
response locale. It will _only_ have a side effect on encoding if not character
encoding is set so far:
{code}
It also sets the response's character encoding appropriately for the locale, if
the character encoding has not been explicitly set using setContentType or
setCharacterEncoding, getWriter hasn't been called yet, and the response hasn't
been committed yet.
{code}
Setting the locale is really important to our framework users. Serving static
resource with various encodings on the other hand is not the usual 80% use
case. I think you should chose out of these two:
1. use UTF-8 all the way, and set {{struts.i18n.encoding=UTF-8}}. This should
take precedence over the encoding side effect of setLocale - if not, this is a
bug to address.
2. place your custom filter after StrutsPrepareFilter and address the encoding
issues you are facing as you specifically need it
I really recommend option 1, UTF-8 is the only true source nowadays :)
But dropping setLocale is really not what we want.
Struts 2 is calling response.setLocale even though it will not handle the
request
-
Key: WW-3651
URL: https://issues.apache.org/jira/browse/WW-3651
Project: Struts 2
Issue Type: Bug
Components: Dispatch Filter
Affects Versions: 2.2.3
Environment: Windows 7, Java 1.6
Reporter: Alfredo Osorio
Fix For: 2.3.16
The org.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter --
org.apache.struts2.dispatcher.Dispatcher.prepare(HttpServletRequest request,
HttpServletResponse response) is calling response.setLocale(locale) when you
specify a default locale (using struts.properties struts.locale). This is
wrong because consider the following example:
This is a static resource stored in the following path:
www.mydomain.com/myApp/scripts/utils.js where myApp is the webcontext and
/scripts/utils.js is a java script file.
1. A request to /myApp/scripts/utils.js.
1. Even though Struts 2 is not going to handle the request
org.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter calls
prepare.setEncodingAndLocale(request, response);
which sets the Request Encoding and the Response Locale.
2. Servlet Container Response setLocale obtains the character encoding
corresponding to that locale and assign a character encoding to the response.
This behavior is correct according to the spec:
http://download.oracle.com/javaee/5/api/javax/servlet/ServletResponse.html#setLocale%28java.util.Locale%29
3. Struts Execute filter doesn't handle the request so
chain.doFilter(request, response); is called.
4. Once all filters are called the servlet container DefaultServlet is called
to handle the request and send the content of the file assigning the response
header Content-Type in which this case it will use the encoding type that was
set before by the StrutsPrepareFilter. This might not correspond to the
actual encoding of the file.
An example of the Header Response Content-Type:
Content-Type application/x-javascript;charset=ISO-8859-1
This only happens when you specify the default locale in the
struts.properties because of these lines in Dispatcher.prepare():
{code:java}
String encoding = null;
if (defaultEncoding != null) {
encoding = defaultEncoding;
}
Locale locale = null;
if (defaultLocale != null) {
[jira] [Commented] (WW-3905) The TextProvider injection in ActionSupport isn't quite integrated into the framework's core DI
[ https://issues.apache.org/jira/browse/WW-3905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770530#comment-13770530 ] Rene Gielen commented on WW-3905: - Got burned once when I wanted to start refactoring here ;) This is a refactoring we might want to address in Struts NEXT, including possible breaking changes ... The TextProvider injection in ActionSupport isn't quite integrated into the framework's core DI Key: WW-3905 URL: https://issues.apache.org/jira/browse/WW-3905 Project: Struts 2 Issue Type: Bug Components: Core Actions Affects Versions: 2.3.4.1 Reporter: chad davis Labels: ActionSupport, DependencyInjection, TextProvider Fix For: 2.3.17 The injection of the TextProvider into ActionSupport occurs via a lazy initialization in the getTextProvider() method. This method obtains the TextProvider from a factory that has the implementation injected into it via the core di mechanism. The problem with this is that ActionSupport programmatically does the injection using it's reference to the core ContainerImpl. This makes it impossible to use the Spring plugin's SpringObjectFactory to manage this TextProvider. -- 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-4193) OGNL WARN msg in log when user enters invalid data
[ https://issues.apache.org/jira/browse/WW-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen resolved WW-4193. - Resolution: Fixed Fix applied. Thanks to Christoph Nenning. OGNL WARN msg in log when user enters invalid data --- Key: WW-4193 URL: https://issues.apache.org/jira/browse/WW-4193 Project: Struts 2 Issue Type: Bug Components: Expression Language, Value Stack Affects Versions: 2.3.15.1 Reporter: Christoph Nenning Assignee: Rene Gielen Priority: Minor Fix For: 2.3.16 Attachments: struts2.patch When a user enters a invalid value, the framework logs a WARN msg with stacktrace. Even when dev mode is disabled. For example: - an Action with an int as member - a form with a text field for that int - user enters a string The framework tries to find a setter for that member (which is successful) and tries to set the value (which fails because the setter has wrong parameter type) Then a stracktrace is logged as WARN. It is a valid use case that users enter invalid data and no stracktrace should be logged (at least not when dev mode is disabled). -- 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-4193) OGNL WARN msg in log when user enters invalid data
[ https://issues.apache.org/jira/browse/WW-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen updated WW-4193: Assignee: Rene Gielen OGNL WARN msg in log when user enters invalid data --- Key: WW-4193 URL: https://issues.apache.org/jira/browse/WW-4193 Project: Struts 2 Issue Type: Bug Components: Expression Language, Value Stack Affects Versions: 2.3.15.1 Reporter: Christoph Nenning Assignee: Rene Gielen Priority: Minor When a user enters a invalid value, the framework logs a WARN msg with stacktrace. Even when dev mode is disabled. For example: - an Action with an int as member - a form with a text field for that int - user enters a string The framework tries to find a setter for that member (which is successful) and tries to set the value (which fails because the setter has wrong parameter type) Then a stracktrace is logged as WARN. It is a valid use case that users enter invalid data and no stracktrace should be logged (at least not when dev mode is disabled). -- 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-4193) OGNL WARN msg in log when user enters invalid data
[ https://issues.apache.org/jira/browse/WW-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen updated WW-4193: Fix Version/s: 2.3.16 OGNL WARN msg in log when user enters invalid data --- Key: WW-4193 URL: https://issues.apache.org/jira/browse/WW-4193 Project: Struts 2 Issue Type: Bug Components: Expression Language, Value Stack Affects Versions: 2.3.15.1 Reporter: Christoph Nenning Assignee: Rene Gielen Priority: Minor Fix For: 2.3.16 When a user enters a invalid value, the framework logs a WARN msg with stacktrace. Even when dev mode is disabled. For example: - an Action with an int as member - a form with a text field for that int - user enters a string The framework tries to find a setter for that member (which is successful) and tries to set the value (which fails because the setter has wrong parameter type) Then a stracktrace is logged as WARN. It is a valid use case that users enter invalid data and no stracktrace should be logged (at least not when dev mode is disabled). -- 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-3714) Rename org.opensymphony.xwork2 to org.apache.struts2.xwork2
[ https://issues.apache.org/jira/browse/WW-3714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13752267#comment-13752267 ] Rene Gielen commented on WW-3714: - Since XWork is not an Apache TLP while Struts is, we should keep Struts in the prefix. So if we rename in the end, I'd rather vote for org.apache.struts.xwork (dropping the 2 stuff). Rename org.opensymphony.xwork2 to org.apache.struts2.xwork2 --- Key: WW-3714 URL: https://issues.apache.org/jira/browse/WW-3714 Project: Struts 2 Issue Type: Task Components: Core Actions Affects Versions: 2.2.3.1 Reporter: Lukasz Lenart Assignee: Lukasz Lenart Priority: Minor Fix For: 3.0 To finish acquisition of XWork project, all the packages have to be renamed to match current Struts 2 package hierarchy -- 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-4178) Question on the Support for Struts2-Struts1 plugin
[ https://issues.apache.org/jira/browse/WW-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen updated WW-4178: Priority: Minor (was: Major) Assignee: Rene Gielen Question on the Support for Struts2-Struts1 plugin -- Key: WW-4178 URL: https://issues.apache.org/jira/browse/WW-4178 Project: Struts 2 Issue Type: Temp Components: Other Affects Versions: 2.3.15.1 Reporter: Vijayalayan Selvaraj Assignee: Rene Gielen Priority: Minor Hi, Sincere Apologies for raising this issue Here. I'm not aware of the process and not sure if I am raising this in the correct forum. Our project is developed on Struts 1.1 and has been running without any issues for the past 5-8 years. As per the recent announcement of EOL for struts 1.x, we are planning to move to Struts 2. As per the migration strategies stated, We are planning to use struts2-struts1-plugin-2.1.8.1.jar in our systems and for any new development we are planning to use Struts 2 framework. With regard to this, we have the following Queries. If we were using this plugin and as stated in the plugin documentations, struts1 jar will still needs to be maintained in order to function correctly, Will there be a scenario of support for this plugin is required, Can we expect any fix from apache to address the issue on the plugin or struts1 jar files. As stated in the website (http://struts.apache.org/development/2.x/docs/struts-1-plugin.html),I'm not able to see the ticket specified for continued use of struts 1 tag libraries in jsps. Can you please share some information about the latest status on this JIRA ticket. Also it will be good, if there are any readily available migration tools from Struts1 to Struts2 for JSPs or Java servlets source code. Once again apologies for raising this in the forum. Many thanks in advance for your help. Regards, Vijay. -- 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-4178) Question on the Support for Struts2-Struts1 plugin
[ https://issues.apache.org/jira/browse/WW-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13740857#comment-13740857 ] Rene Gielen commented on WW-4178: - Vijay, to get support for usage and best practices regarding the Struts 2 to Struts 1 bridge plugin, please ask your questions on the user mailing list. See http://struts.apache.org/mail.html on how it works and how to subscribe. As for the JSP issue, the broken link references this ticket: https://issues.apache.org/jira/browse/WW-2157. Most likely there will be no further efforts to fix this from the Struts committers. If you want to discuss this issue or maybe want to contribute, please ask your questions on the Struts developer list as found as well in the first provided link. Anyway, please make sure that your are basing your development on Struts = 2.3.15.1, since all previous versions contain several critical security vulnerabilities. Ensure to have consistent versioning among all Struts 2 libraries used in your project. That is, use at least struts2-struts1-plugin-2.3.15.1.jar along with Struts 2 libraries matching the same version. Question on the Support for Struts2-Struts1 plugin -- Key: WW-4178 URL: https://issues.apache.org/jira/browse/WW-4178 Project: Struts 2 Issue Type: Temp Components: Other Affects Versions: 2.3.15.1 Reporter: Vijayalayan Selvaraj Assignee: Rene Gielen Priority: Minor Hi, Sincere Apologies for raising this issue Here. I'm not aware of the process and not sure if I am raising this in the correct forum. Our project is developed on Struts 1.1 and has been running without any issues for the past 5-8 years. As per the recent announcement of EOL for struts 1.x, we are planning to move to Struts 2. As per the migration strategies stated, We are planning to use struts2-struts1-plugin-2.1.8.1.jar in our systems and for any new development we are planning to use Struts 2 framework. With regard to this, we have the following Queries. If we were using this plugin and as stated in the plugin documentations, struts1 jar will still needs to be maintained in order to function correctly, Will there be a scenario of support for this plugin is required, Can we expect any fix from apache to address the issue on the plugin or struts1 jar files. As stated in the website (http://struts.apache.org/development/2.x/docs/struts-1-plugin.html),I'm not able to see the ticket specified for continued use of struts 1 tag libraries in jsps. Can you please share some information about the latest status on this JIRA ticket. Also it will be good, if there are any readily available migration tools from Struts1 to Struts2 for JSPs or Java servlets source code. Once again apologies for raising this in the forum. Many thanks in advance for your help. Regards, Vijay. -- 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-4178) Question on the Support for Struts2-Struts1 plugin
[ https://issues.apache.org/jira/browse/WW-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen closed WW-4178. --- Resolution: Invalid This was a support request, not an issue Question on the Support for Struts2-Struts1 plugin -- Key: WW-4178 URL: https://issues.apache.org/jira/browse/WW-4178 Project: Struts 2 Issue Type: Temp Components: Other Affects Versions: 2.3.15.1 Reporter: Vijayalayan Selvaraj Assignee: Rene Gielen Priority: Minor Hi, Sincere Apologies for raising this issue Here. I'm not aware of the process and not sure if I am raising this in the correct forum. Our project is developed on Struts 1.1 and has been running without any issues for the past 5-8 years. As per the recent announcement of EOL for struts 1.x, we are planning to move to Struts 2. As per the migration strategies stated, We are planning to use struts2-struts1-plugin-2.1.8.1.jar in our systems and for any new development we are planning to use Struts 2 framework. With regard to this, we have the following Queries. If we were using this plugin and as stated in the plugin documentations, struts1 jar will still needs to be maintained in order to function correctly, Will there be a scenario of support for this plugin is required, Can we expect any fix from apache to address the issue on the plugin or struts1 jar files. As stated in the website (http://struts.apache.org/development/2.x/docs/struts-1-plugin.html),I'm not able to see the ticket specified for continued use of struts 1 tag libraries in jsps. Can you please share some information about the latest status on this JIRA ticket. Also it will be good, if there are any readily available migration tools from Struts1 to Struts2 for JSPs or Java servlets source code. Once again apologies for raising this in the forum. Many thanks in advance for your help. Regards, Vijay. -- 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-4171) getText methods are not documented as evaluating OGNL
[ https://issues.apache.org/jira/browse/WW-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731815#comment-13731815 ] Rene Gielen commented on WW-4171: - [~lukaszlenart] Yeah, the problem is that calls to getText with expressions may make sense. So you would only want to sanitize user input, but not any API call. That said, introducing such annotations would make even more sense if we'd finally introduce a central sanitization API! Say a central sanitizer class with static methods like sanitize(String), sanitize(String, SanitizingOptions ... options) Combined with static imports, a safe call to getText(@SanitizingRequired String message) would look like getText(sanitize(userModifieableProperty)). The actual sanitizer implementation should be Interface-based, with the Sanitizer class being a static facade using static injection / a factory for a singleton sanitizer implementation. Thus we could provide different sanitizers for different ELs used now and in future. WDYT? getText methods are not documented as evaluating OGNL - Key: WW-4171 URL: https://issues.apache.org/jira/browse/WW-4171 Project: Struts 2 Issue Type: Improvement Components: Documentation Affects Versions: 2.3.15.1 Reporter: Coverity Security Research Laboratory Assignee: Lukasz Lenart Priority: Minor Labels: security Fix For: 2.3.16 The methods below evaluate OGNL as their first parameter. However they are not documented as evaluating OGNL. We have observed this occurring in one project and are contacting the affected vendors. com.opensymphony.xwork2.TextProviderSupport.getText(String, String[]) com.opensymphony.xwork2.TextProviderSupport.getText(String, List?) com.opensymphony.xwork2.TextProviderSupport.getText(String) These methods are then used by ActionSupport (via its getText methods). None of these methods are documented as evaluating OGNL either. This issue is recommending that all of these methods are documented as evaluating OGNL since this may come as a surprise to some developers. -- 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] [Comment Edited] (WW-4171) getText methods are not documented as evaluating OGNL
[
https://issues.apache.org/jira/browse/WW-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731861#comment-13731861
]
Rene Gielen edited comment on WW-4171 at 8/7/13 10:44 AM:
--
[~lukaszlenart] How would you track a value is sanitized beforehand? Since we
encourage use of simple Java types, it might be hard to add metadata to a
property to describe whether sanitizing is required or done already.
IMO ParametersInterceptor's responsibility is to prevent evaluation of
expressions while setting parameter properties. But in the end, the now filled
property may now contain an expression which was not evaluated yet, but might
get evaluated by some API calls in the Action code (see getText(username)).
What is the best way to prevent users from shooting their feet without loosing
flexibility?
Going one step further, how about that:
{code:java}
public enum SanitizingStrategy {
WARN, CLEANUP, REJECT
}
{code}
{code:java}
@Documented
public @interface Sanitized {
SanitizingStrategy value() default SanitizingStrategy.CLEANUP;
SanitizingOptions[] options() default {SanitizingOptions.DETECT_EL};
}
{code}
{code:java}
public class HelloWorld extends ExampleSupport {
public String execute() throws Exception {
setMessage(getText(message));
setOtherMessage(getText(sanitize(manuallySanitizedMessage)));
return SUCCESS;
}
@Sanitized()
private String message;
private String manuallySanitizedMessage;
//...
}
{code}
whereby a SanitizingInterceptor would be in the stack to apply sanitizing based
on the given @Sanitize annotations, using the Sanitizer-API described in my
earlier comment?
was (Author: rgielen):
[~lukaszlenart] How would you track a value is sanitized beforehand? Since
we encourage use of simple Java types, it might be hard to add metadate to a
property whether sanitizing is required or done already.
IMO ParametersInterceptor's responsibility is to prevent evaluation of
expressions while setting parameter properties. But in the end, the now filled
property may now contain an expression which was not evaluated yet, but might
get evaluated by some API calls in the Action code (see getText(username)).
What is the best way to prevent users from shooting their feet without loosing
flexibility?
Going one step further, how about that:
{code:java}
public enum SanitizingStrategy {
WARN, CLEANUP, REJECT
}
{code}
{code:java}
@Documented
public @interface Sanitized {
SanitizingStrategy value() default SanitizingStrategy.CLEANUP;
SanitizingOptions[] options() default {SanitizingOptions.DETECT_EL};
}
{code}
{code:java}
public class HelloWorld extends ExampleSupport {
public String execute() throws Exception {
setMessage(getText(message));
setOtherMessage(getText(sanitize(manuallySanitizedMessage)));
return SUCCESS;
}
@Sanitized()
private String message;
private String manuallySanitizedMessage;
//...
}
{code}
whereby a SanitizingInterceptor would be in the stack to apply sanitizing based
on the given @Sanitize annotations, using the Sanitizer-API described in my
earlier comment?
getText methods are not documented as evaluating OGNL
-
Key: WW-4171
URL: https://issues.apache.org/jira/browse/WW-4171
Project: Struts 2
Issue Type: Improvement
Components: Documentation
Affects Versions: 2.3.15.1
Reporter: Coverity Security Research Laboratory
Assignee: Lukasz Lenart
Priority: Minor
Labels: security
Fix For: 2.3.16
The methods below evaluate OGNL as their first parameter. However they are
not documented as evaluating OGNL. We have observed this occurring in one
project and are contacting the affected vendors.
com.opensymphony.xwork2.TextProviderSupport.getText(String, String[])
com.opensymphony.xwork2.TextProviderSupport.getText(String, List?)
com.opensymphony.xwork2.TextProviderSupport.getText(String)
These methods are then used by ActionSupport (via its getText methods). None
of these methods are documented as evaluating OGNL either.
This issue is recommending that all of these methods are documented as
evaluating OGNL since this may come as a surprise to some developers.
--
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-4171) getText methods are not documented as evaluating OGNL
[
https://issues.apache.org/jira/browse/WW-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731861#comment-13731861
]
Rene Gielen commented on WW-4171:
-
[~lukaszlenart] How would you track a value is sanitized beforehand? Since we
encourage use of simple Java types, it might be hard to add metadate to a
property whether sanitizing is required or done already.
IMO ParametersInterceptor's responsibility is to prevent evaluation of
expressions while setting parameter properties. But in the end, the now filled
property may now contain an expression which was not evaluated yet, but might
get evaluated by some API calls in the Action code (see getText(username)).
What is the best way to prevent users from shooting their feet without loosing
flexibility?
Going one step further, how about that:
{code:java}
public enum SanitizingStrategy {
WARN, CLEANUP, REJECT
}
{code}
{code:java}
@Documented
public @interface Sanitized {
SanitizingStrategy value() default SanitizingStrategy.CLEANUP;
SanitizingOptions[] options() default {SanitizingOptions.DETECT_EL};
}
{code}
{code:java}
public class HelloWorld extends ExampleSupport {
public String execute() throws Exception {
setMessage(getText(message));
setOtherMessage(getText(sanitize(manuallySanitizedMessage)));
return SUCCESS;
}
@Sanitized()
private String message;
private String manuallySanitizedMessage;
//...
}
{code}
whereby a SanitizingInterceptor would be in the stack to apply sanitizing based
on the given @Sanitize annotations, using the Sanitizer-API described in my
earlier comment?
getText methods are not documented as evaluating OGNL
-
Key: WW-4171
URL: https://issues.apache.org/jira/browse/WW-4171
Project: Struts 2
Issue Type: Improvement
Components: Documentation
Affects Versions: 2.3.15.1
Reporter: Coverity Security Research Laboratory
Assignee: Lukasz Lenart
Priority: Minor
Labels: security
Fix For: 2.3.16
The methods below evaluate OGNL as their first parameter. However they are
not documented as evaluating OGNL. We have observed this occurring in one
project and are contacting the affected vendors.
com.opensymphony.xwork2.TextProviderSupport.getText(String, String[])
com.opensymphony.xwork2.TextProviderSupport.getText(String, List?)
com.opensymphony.xwork2.TextProviderSupport.getText(String)
These methods are then used by ActionSupport (via its getText methods). None
of these methods are documented as evaluating OGNL either.
This issue is recommending that all of these methods are documented as
evaluating OGNL since this may come as a surprise to some developers.
--
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-4171) getText methods are not documented as evaluating OGNL
[ https://issues.apache.org/jira/browse/WW-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731891#comment-13731891 ] Rene Gielen commented on WW-4171: - It only makes sense to sanitize before setting the value, since the annotation information will be lost when the passed as parameter to an API call. Thus, there are basically two options: 1. make Sanitizing a delegate call in ParametersInterceptor 2. break up steps to separate concerns Regarding 2, combined with an earlier (less elaborate) idea: a possible workflow, each step implemented by interceptors, could look like this 1. prepare naked parameter map, mapping request key-value-pairs to simple Map 2. sanitize parameter keys, as strict as we do now in ParametersInterceptor; replace map / map keys / entries from step one so that paramter map now only contains sanitized key values 3. sanitize parameter values based on evaluating keys against the stack, introspect candidate properties; if a candidate property (or its class!) contains the @Sanitize annotation, sanitize value based on this directive; replace map / map values / entries from step two so that paramter map now only contains sanitized keys and values. Important: only the map is sanitized, no model property in the stack is touched yet! 4. set parameters on the model, based on the sanitized map. Basically this is a more lightweight version of nowadays ParametersInterceptor Point 4 is interesting, since now ParametersInterceptor would only serve a single concern. Also, paramPrepareParam would get more lightweight since the already sanitized parameter map would be used for both ParametersInterceptor calls. No need to sanitize two times then getText methods are not documented as evaluating OGNL - Key: WW-4171 URL: https://issues.apache.org/jira/browse/WW-4171 Project: Struts 2 Issue Type: Improvement Components: Documentation Affects Versions: 2.3.15.1 Reporter: Coverity Security Research Laboratory Assignee: Lukasz Lenart Priority: Minor Labels: security Fix For: 2.3.16 The methods below evaluate OGNL as their first parameter. However they are not documented as evaluating OGNL. We have observed this occurring in one project and are contacting the affected vendors. com.opensymphony.xwork2.TextProviderSupport.getText(String, String[]) com.opensymphony.xwork2.TextProviderSupport.getText(String, List?) com.opensymphony.xwork2.TextProviderSupport.getText(String) These methods are then used by ActionSupport (via its getText methods). None of these methods are documented as evaluating OGNL either. This issue is recommending that all of these methods are documented as evaluating OGNL since this may come as a surprise to some developers. -- 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-4171) getText methods are not documented as evaluating OGNL
[ https://issues.apache.org/jira/browse/WW-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731903#comment-13731903 ] Rene Gielen commented on WW-4171: - An OGNL PropertyAccessor implementation (not targeted to specific classes, though) might do the trick. But this has to be solved to implement such a strategy, yes! getText methods are not documented as evaluating OGNL - Key: WW-4171 URL: https://issues.apache.org/jira/browse/WW-4171 Project: Struts 2 Issue Type: Improvement Components: Documentation Affects Versions: 2.3.15.1 Reporter: Coverity Security Research Laboratory Assignee: Lukasz Lenart Priority: Minor Labels: security Fix For: 2.3.16 The methods below evaluate OGNL as their first parameter. However they are not documented as evaluating OGNL. We have observed this occurring in one project and are contacting the affected vendors. com.opensymphony.xwork2.TextProviderSupport.getText(String, String[]) com.opensymphony.xwork2.TextProviderSupport.getText(String, List?) com.opensymphony.xwork2.TextProviderSupport.getText(String) These methods are then used by ActionSupport (via its getText methods). None of these methods are documented as evaluating OGNL either. This issue is recommending that all of these methods are documented as evaluating OGNL since this may come as a surprise to some developers. -- 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] [Deleted] (WW-4172) deleteing
[ https://issues.apache.org/jira/browse/WW-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen deleted WW-4172: deleteing - Key: WW-4172 URL: https://issues.apache.org/jira/browse/WW-4172 Project: Struts 2 Issue Type: Bug 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] [Commented] (WW-4171) getText methods are not documented as evaluating OGNL
[
https://issues.apache.org/jira/browse/WW-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730951#comment-13730951
]
Rene Gielen commented on WW-4171:
-
[~d...@solaraccess.com] No, parameter processing should be safe here - message
property will contain ${2*3} after ParametersInterceptor; but passing the so
far unevaluated expression string to getText() will force an OGNL evaluation in
Jon's example.
So far I see a passing unsanitized user input to an API issue, which is
generally a questionable idea. I agree with Jon that the API JavaDocs should
state clearly that expression evaluation will take place, such that users are
warned. Nevertheless, I don't see we need further actions like active
prevention and such.
Just an idea: even more valuable than simple JavaDoc could be an annotation for
parameters, like @SanitizingRequired or @ExpressionAware...
getText methods are not documented as evaluating OGNL
-
Key: WW-4171
URL: https://issues.apache.org/jira/browse/WW-4171
Project: Struts 2
Issue Type: Improvement
Components: Documentation
Affects Versions: 2.3.15.1
Reporter: Coverity Security Research Laboratory
Assignee: Lukasz Lenart
Priority: Minor
Labels: security
Fix For: 2.3.16
The methods below evaluate OGNL as their first parameter. However they are
not documented as evaluating OGNL. We have observed this occurring in one
project and are contacting the affected vendors.
com.opensymphony.xwork2.TextProviderSupport.getText(String, String[])
com.opensymphony.xwork2.TextProviderSupport.getText(String, List?)
com.opensymphony.xwork2.TextProviderSupport.getText(String)
These methods are then used by ActionSupport (via its getText methods). None
of these methods are documented as evaluating OGNL either.
This issue is recommending that all of these methods are documented as
evaluating OGNL since this may come as a surprise to some developers.
--
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-4157) Move docs export to Maven release phase
[ https://issues.apache.org/jira/browse/WW-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722273#comment-13722273 ] Rene Gielen commented on WW-4157: - I see the problem, and we may want to rethink whether we would want to switch default so that skipAssembly is true unless you define otherwise (which is easy to document for release managers). However, the phase package is absolutely correct and we would never want to move this step to the release phase. How would you prepare a local build including docs without releasing or even installing then? Move docs export to Maven release phase --- Key: WW-4157 URL: https://issues.apache.org/jira/browse/WW-4157 Project: Struts 2 Issue Type: Improvement Components: Build Management Affects Versions: 2.3.15.1 Reporter: Serdyn du Toit Fix For: 2.3.16 Currently a basic mvn install or mvn package prompts for a username and password. This is not ideal. As per the dev mailing list: This is needed to prepare a new release as right now we directly hit Confluence to export docs. Can you register an issue for that? It would be better to docs export to release phase. It isn't needed for normal builds. Temporary workaround: Start build with -DskipAssembly to skip the whole assembly module. -- 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-4140) Security Improvement
Rene Gielen created WW-4140: --- Summary: Security Improvement Key: WW-4140 URL: https://issues.apache.org/jira/browse/WW-4140 Project: Struts 2 Issue Type: Bug Components: Core Actions Affects Versions: 2.3.15 Reporter: Rene Gielen Assignee: Rene Gielen Fix For: 2.3.15.1, 2.3.16 -- 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-4140) Security Improvement
[ https://issues.apache.org/jira/browse/WW-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen updated WW-4140: Description: CVE-2013-2248 CVE-2013-2251 was: CVE-2013-2248 Open Redirect CVE-2013-2251 Remote Command Execution Triggered by action: / redirect: Parameters Security Improvement Key: WW-4140 URL: https://issues.apache.org/jira/browse/WW-4140 Project: Struts 2 Issue Type: Bug Components: Core Actions Affects Versions: 2.3.15 Reporter: Rene Gielen Assignee: Rene Gielen Labels: security Fix For: 2.3.15.1, 2.3.16 CVE-2013-2248 CVE-2013-2251 -- 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-4140) Security Improvement
[ https://issues.apache.org/jira/browse/WW-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen updated WW-4140: Description: CVE-2013-2248 Open Redirect CVE-2013-2251 Remote Command Execution Triggered by action: / redirect: Parameters Security Improvement Key: WW-4140 URL: https://issues.apache.org/jira/browse/WW-4140 Project: Struts 2 Issue Type: Bug Components: Core Actions Affects Versions: 2.3.15 Reporter: Rene Gielen Assignee: Rene Gielen Labels: security Fix For: 2.3.15.1, 2.3.16 CVE-2013-2248 Open Redirect CVE-2013-2251 Remote Command Execution Triggered by action: / redirect: Parameters -- 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-4140) Security Improvement
[ https://issues.apache.org/jira/browse/WW-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen closed WW-4140. --- Resolution: Fixed Patch applied Security Improvement Key: WW-4140 URL: https://issues.apache.org/jira/browse/WW-4140 Project: Struts 2 Issue Type: Bug Components: Core Actions Affects Versions: 2.3.15 Reporter: Rene Gielen Assignee: Rene Gielen Labels: security Fix For: 2.3.15.1, 2.3.16 CVE-2013-2248 CVE-2013-2251 -- 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-3873) file tag leaks server path information
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-3873:
Fix Version/s: 2.3.15.1
file tag leaks server path information
--
Key: WW-3873
URL: https://issues.apache.org/jira/browse/WW-3873
Project: Struts 2
Issue Type: Bug
Affects Versions: 2.3.4, 2.3.4.1
Environment: Linux, weblogic 10-12, tomcat 7
Reporter: Cam Morris
Assignee: Rene Gielen
Priority: Minor
Fix For: 2.3.15.1, 2.3.16
Attachments: file-leak.png
After a fileupload action, if the result jsp contains a s:file tag the
value attribute is filled in with the server path where the file was saved.
This discloses file system information about the server.
To duplicate:
1) setup the struts2_showcase sample app
2) change struts-fileupload.xml from this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction
method=upload
result name=inputupload.jsp/result
resultupload-success.jsp/result
/action
{code}
to this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction
method=upload
result name=inputupload.jsp/result
resultupload.jsp/result
/action
{code}
3. Deploy Upload file using the url
struts2-showcase/fileupload/upload.action
4. View source, in the input tag generated by the s:file tag you'll see the
full path to the file that was uploaded.
{code}
input type=file name=upload
value=/home/cmorris/Workspace/struts2-examples/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/work/Catalina/localhost/struts2-showcase/upload__1bd5a0ad_13997105f96__8000_0002.tmp
id=doUpload_upload/
{code}
Workaround:
A workaround is simple, just add an empty value attribute to the file tag:
{code}
s:file name=upload label=File value=/
{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] [Closed] (WW-3873) file tag leaks server path information
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen closed WW-3873.
---
Resolution: Fixed
Changed file tag to always render empty value
file tag leaks server path information
--
Key: WW-3873
URL: https://issues.apache.org/jira/browse/WW-3873
Project: Struts 2
Issue Type: Bug
Affects Versions: 2.3.4, 2.3.4.1
Environment: Linux, weblogic 10-12, tomcat 7
Reporter: Cam Morris
Assignee: Rene Gielen
Priority: Minor
Fix For: 2.3.15.1, 2.3.16
Attachments: file-leak.png
After a fileupload action, if the result jsp contains a s:file tag the
value attribute is filled in with the server path where the file was saved.
This discloses file system information about the server.
To duplicate:
1) setup the struts2_showcase sample app
2) change struts-fileupload.xml from this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction
method=upload
result name=inputupload.jsp/result
resultupload-success.jsp/result
/action
{code}
to this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction
method=upload
result name=inputupload.jsp/result
resultupload.jsp/result
/action
{code}
3. Deploy Upload file using the url
struts2-showcase/fileupload/upload.action
4. View source, in the input tag generated by the s:file tag you'll see the
full path to the file that was uploaded.
{code}
input type=file name=upload
value=/home/cmorris/Workspace/struts2-examples/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/work/Catalina/localhost/struts2-showcase/upload__1bd5a0ad_13997105f96__8000_0002.tmp
id=doUpload_upload/
{code}
Workaround:
A workaround is simple, just add an empty value attribute to the file tag:
{code}
s:file name=upload label=File value=/
{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-3873) file tag leaks server path information
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-3873:
Assignee: Rene Gielen
file tag leaks server path information
--
Key: WW-3873
URL: https://issues.apache.org/jira/browse/WW-3873
Project: Struts 2
Issue Type: Bug
Affects Versions: 2.3.4, 2.3.4.1
Environment: Linux, weblogic 10-12, tomcat 7
Reporter: Cam Morris
Assignee: Rene Gielen
Priority: Minor
Fix For: 2.3.16
Attachments: file-leak.png
After a fileupload action, if the result jsp contains a s:file tag the
value attribute is filled in with the server path where the file was saved.
This discloses file system information about the server.
To duplicate:
1) setup the struts2_showcase sample app
2) change struts-fileupload.xml from this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction
method=upload
result name=inputupload.jsp/result
resultupload-success.jsp/result
/action
{code}
to this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction
method=upload
result name=inputupload.jsp/result
resultupload.jsp/result
/action
{code}
3. Deploy Upload file using the url
struts2-showcase/fileupload/upload.action
4. View source, in the input tag generated by the s:file tag you'll see the
full path to the file that was uploaded.
{code}
input type=file name=upload
value=/home/cmorris/Workspace/struts2-examples/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/work/Catalina/localhost/struts2-showcase/upload__1bd5a0ad_13997105f96__8000_0002.tmp
id=doUpload_upload/
{code}
Workaround:
A workaround is simple, just add an empty value attribute to the file tag:
{code}
s:file name=upload label=File value=/
{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] [Issue Comment Deleted] (WW-3873) file tag leaks server path information
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-3873:
Comment: was deleted
(was: I will be out of the office until July 5th
On Jul 5, 2013, at 1:29 AM, Rene Gielen (JIRA) j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-3873:
Assignee: Rene Gielen
file tag leaks server path information
--
Key: WW-3873
URL: https://issues.apache.org/jira/browse/WW-3873
Project: Struts 2
Issue Type: Bug
Affects Versions: 2.3.4, 2.3.4.1
Environment: Linux, weblogic 10-12, tomcat 7
Reporter: Cam Morris
Assignee: Rene Gielen
Priority: Minor
Fix For: 2.3.16
Attachments: file-leak.png
After a fileupload action, if the result jsp contains a s:file tag the value
attribute is filled in with the server path where the file was saved. This
discloses file system information about the server.
To duplicate:
1) setup the struts2_showcase sample app
2) change struts-fileupload.xml from this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction method=upload
result name=inputupload.jsp/result
resultupload-success.jsp/result
/action
{code}
to this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction method=upload
result name=inputupload.jsp/result
resultupload.jsp/result
/action
{code}
3. Deploy Upload file using the url struts2-showcase/fileupload/upload.action
4. View source, in the input tag generated by the s:file tag you'll see the
full path to the file that was uploaded.
{code}
input type=file name=upload
value=/home/cmorris/Workspace/struts2-examples/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/work/Catalina/localhost/struts2-showcase/upload__1bd5a0ad_13997105f96__8000_0002.tmp
id=doUpload_upload/
{code}
Workaround:
A workaround is simple, just add an empty value attribute to the file tag:
{code}
s:file name=upload label=File value=/
{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
)
file tag leaks server path information
--
Key: WW-3873
URL: https://issues.apache.org/jira/browse/WW-3873
Project: Struts 2
Issue Type: Bug
Affects Versions: 2.3.4, 2.3.4.1
Environment: Linux, weblogic 10-12, tomcat 7
Reporter: Cam Morris
Assignee: Rene Gielen
Priority: Minor
Fix For: 2.3.16
Attachments: file-leak.png
After a fileupload action, if the result jsp contains a s:file tag the
value attribute is filled in with the server path where the file was saved.
This discloses file system information about the server.
To duplicate:
1) setup the struts2_showcase sample app
2) change struts-fileupload.xml from this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction
method=upload
result name=inputupload.jsp/result
resultupload-success.jsp/result
/action
{code}
to this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction
method=upload
result name=inputupload.jsp/result
resultupload.jsp/result
/action
{code}
3. Deploy Upload file using the url
struts2-showcase/fileupload/upload.action
4. View source, in the input tag generated by the s:file tag you'll see the
full path to the file that was uploaded.
{code}
input type=file name=upload
value=/home/cmorris/Workspace/struts2-examples/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/work/Catalina/localhost/struts2-showcase/upload__1bd5a0ad_13997105f96__8000_0002.tmp
id=doUpload_upload/
{code}
Workaround:
A workaround is simple, just add an empty value attribute to the file tag:
{code}
s:file name=upload label=File value=/
{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] [Issue Comment Deleted] (WW-3873) file tag leaks server path information
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-3873:
Comment: was deleted
(was: I will be out of the office until July 5th
On Jul 5, 2013, at 7:32 AM, nathan.comst...@wellsfargo.com (JIRA)
j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700844#comment-13700844
]
nathan.comst...@wellsfargo.com commented on WW-3873:
I will be out of the office until July 5th
On Jul 5, 2013, at 7:28 AM, nathan.comst...@wellsfargo.com (JIRA)
j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700810#comment-13700810
]
nathan.comst...@wellsfargo.com commented on WW-3873:
I will be out of the office until July 5th
On Jul 5, 2013, at 7:24 AM, nathan.comst...@wellsfargo.com (JIRA)
j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700773#comment-13700773
]
nathan.comst...@wellsfargo.com commented on WW-3873:
I will be out of the office until July 5th
On Jul 5, 2013, at 7:21 AM, nathan.comst...@wellsfargo.com (JIRA)
j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700729#comment-13700729
]
nathan.comst...@wellsfargo.com commented on WW-3873:
I will be out of the office until July 5th
On Jul 5, 2013, at 1:29 AM, Rene Gielen (JIRA) j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-3873:
Assignee: Rene Gielen
file tag leaks server path information
--
Key: WW-3873
URL: https://issues.apache.org/jira/browse/WW-3873
Project: Struts 2
Issue Type: Bug
Affects Versions: 2.3.4, 2.3.4.1
Environment: Linux, weblogic 10-12, tomcat 7
Reporter: Cam Morris
Assignee: Rene Gielen
Priority: Minor
Fix For: 2.3.16
Attachments: file-leak.png
After a fileupload action, if the result jsp contains a s:file tag the value
attribute is filled in with the server path where the file was saved. This
discloses file system information about the server.
To duplicate:
1) setup the struts2_showcase sample app
2) change struts-fileupload.xml from this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction method=upload
result name=inputupload.jsp/result
resultupload-success.jsp/result
/action
{code}
to this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction method=upload
result name=inputupload.jsp/result
resultupload.jsp/result
/action
{code}
3. Deploy Upload file using the url struts2-showcase/fileupload/upload.action
4. View source, in the input tag generated by the s:file tag you'll see the
full path to the file that was uploaded.
{code}
input type=file name=upload
value=/home/cmorris/Workspace/struts2-examples/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/work/Catalina/localhost/struts2-showcase/upload__1bd5a0ad_13997105f96__8000_0002.tmp
id=doUpload_upload/
{code}
Workaround:
A workaround is simple, just add an empty value attribute to the file tag:
{code}
s:file name=upload label=File value=/
{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
file tag leaks server path information
--
Key: WW-3873
URL: https://issues.apache.org/jira/browse/WW-3873
Project: Struts 2
Issue Type: Bug
Affects Versions: 2.3.4, 2.3.4.1
Environment: Linux, weblogic 10-12, tomcat 7
Reporter: Cam Morris
Assignee: Rene Gielen
Priority: Minor
Fix For: 2.3.16
Attachments: file-leak.png
After a fileupload action, if the result jsp contains a s:file tag the value
attribute is filled in with the server path where the file was saved. This
discloses file system information about the server.
To duplicate:
1) setup the struts2_showcase sample app
2) change struts-fileupload.xml from this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction method=upload
[jira] [Issue Comment Deleted] (WW-3873) file tag leaks server path information
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-3873:
Comment: was deleted
(was: I will be out of the office until July 5th
On Jul 5, 2013, at 7:24 AM, nathan.comst...@wellsfargo.com (JIRA)
j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700773#comment-13700773
]
nathan.comst...@wellsfargo.com commented on WW-3873:
I will be out of the office until July 5th
On Jul 5, 2013, at 7:21 AM, nathan.comst...@wellsfargo.com (JIRA)
j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700729#comment-13700729
]
nathan.comst...@wellsfargo.com commented on WW-3873:
I will be out of the office until July 5th
On Jul 5, 2013, at 1:29 AM, Rene Gielen (JIRA) j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-3873:
Assignee: Rene Gielen
file tag leaks server path information
--
Key: WW-3873
URL: https://issues.apache.org/jira/browse/WW-3873
Project: Struts 2
Issue Type: Bug
Affects Versions: 2.3.4, 2.3.4.1
Environment: Linux, weblogic 10-12, tomcat 7
Reporter: Cam Morris
Assignee: Rene Gielen
Priority: Minor
Fix For: 2.3.16
Attachments: file-leak.png
After a fileupload action, if the result jsp contains a s:file tag the value
attribute is filled in with the server path where the file was saved. This
discloses file system information about the server.
To duplicate:
1) setup the struts2_showcase sample app
2) change struts-fileupload.xml from this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction method=upload
result name=inputupload.jsp/result
resultupload-success.jsp/result
/action
{code}
to this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction method=upload
result name=inputupload.jsp/result
resultupload.jsp/result
/action
{code}
3. Deploy Upload file using the url struts2-showcase/fileupload/upload.action
4. View source, in the input tag generated by the s:file tag you'll see the
full path to the file that was uploaded.
{code}
input type=file name=upload
value=/home/cmorris/Workspace/struts2-examples/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/work/Catalina/localhost/struts2-showcase/upload__1bd5a0ad_13997105f96__8000_0002.tmp
id=doUpload_upload/
{code}
Workaround:
A workaround is simple, just add an empty value attribute to the file tag:
{code}
s:file name=upload label=File value=/
{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
file tag leaks server path information
--
Key: WW-3873
URL: https://issues.apache.org/jira/browse/WW-3873
Project: Struts 2
Issue Type: Bug
Affects Versions: 2.3.4, 2.3.4.1
Environment: Linux, weblogic 10-12, tomcat 7
Reporter: Cam Morris
Assignee: Rene Gielen
Priority: Minor
Fix For: 2.3.16
Attachments: file-leak.png
After a fileupload action, if the result jsp contains a s:file tag the value
attribute is filled in with the server path where the file was saved. This
discloses file system information about the server.
To duplicate:
1) setup the struts2_showcase sample app
2) change struts-fileupload.xml from this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction method=upload
result name=inputupload.jsp/result
resultupload-success.jsp/result
/action
{code}
to this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction method=upload
result name=inputupload.jsp/result
resultupload.jsp/result
/action
{code}
3. Deploy Upload file using the url struts2-showcase/fileupload/upload.action
4. View source, in the input tag generated by the s:file tag you'll see the
full path to the file that was uploaded.
{code}
input type=file name=upload
value=/home/cmorris/Workspace/struts2-examples/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/work/Catalina/localhost/struts2-showcase
[jira] [Issue Comment Deleted] (WW-3873) file tag leaks server path information
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-3873:
Comment: was deleted
(was: I will be out of the office until July 5th
On Jul 5, 2013, at 7:28 AM, nathan.comst...@wellsfargo.com (JIRA)
j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700810#comment-13700810
]
nathan.comst...@wellsfargo.com commented on WW-3873:
I will be out of the office until July 5th
On Jul 5, 2013, at 7:24 AM, nathan.comst...@wellsfargo.com (JIRA)
j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700773#comment-13700773
]
nathan.comst...@wellsfargo.com commented on WW-3873:
I will be out of the office until July 5th
On Jul 5, 2013, at 7:21 AM, nathan.comst...@wellsfargo.com (JIRA)
j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700729#comment-13700729
]
nathan.comst...@wellsfargo.com commented on WW-3873:
I will be out of the office until July 5th
On Jul 5, 2013, at 1:29 AM, Rene Gielen (JIRA) j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/WW-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-3873:
Assignee: Rene Gielen
file tag leaks server path information
--
Key: WW-3873
URL: https://issues.apache.org/jira/browse/WW-3873
Project: Struts 2
Issue Type: Bug
Affects Versions: 2.3.4, 2.3.4.1
Environment: Linux, weblogic 10-12, tomcat 7
Reporter: Cam Morris
Assignee: Rene Gielen
Priority: Minor
Fix For: 2.3.16
Attachments: file-leak.png
After a fileupload action, if the result jsp contains a s:file tag the value
attribute is filled in with the server path where the file was saved. This
discloses file system information about the server.
To duplicate:
1) setup the struts2_showcase sample app
2) change struts-fileupload.xml from this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction method=upload
result name=inputupload.jsp/result
resultupload-success.jsp/result
/action
{code}
to this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction method=upload
result name=inputupload.jsp/result
resultupload.jsp/result
/action
{code}
3. Deploy Upload file using the url struts2-showcase/fileupload/upload.action
4. View source, in the input tag generated by the s:file tag you'll see the
full path to the file that was uploaded.
{code}
input type=file name=upload
value=/home/cmorris/Workspace/struts2-examples/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/work/Catalina/localhost/struts2-showcase/upload__1bd5a0ad_13997105f96__8000_0002.tmp
id=doUpload_upload/
{code}
Workaround:
A workaround is simple, just add an empty value attribute to the file tag:
{code}
s:file name=upload label=File value=/
{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
file tag leaks server path information
--
Key: WW-3873
URL: https://issues.apache.org/jira/browse/WW-3873
Project: Struts 2
Issue Type: Bug
Affects Versions: 2.3.4, 2.3.4.1
Environment: Linux, weblogic 10-12, tomcat 7
Reporter: Cam Morris
Assignee: Rene Gielen
Priority: Minor
Fix For: 2.3.16
Attachments: file-leak.png
After a fileupload action, if the result jsp contains a s:file tag the value
attribute is filled in with the server path where the file was saved. This
discloses file system information about the server.
To duplicate:
1) setup the struts2_showcase sample app
2) change struts-fileupload.xml from this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction method=upload
result name=inputupload.jsp/result
resultupload-success.jsp/result
/action
{code}
to this
{code}
action name=doUpload
class=org.apache.struts2.showcase.fileupload.FileUploadAction method=upload
result name=inputupload.jsp/result
resultupload.jsp/result
/action
{code}
3. Deploy Upload file
[jira] [Closed] (WW-4136) Demonstrate proper input sanitizing for file download showcase example
[ https://issues.apache.org/jira/browse/WW-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen closed WW-4136. --- Resolution: Fixed Added demo code to sanitize input path parameter Demonstrate proper input sanitizing for file download showcase example -- Key: WW-4136 URL: https://issues.apache.org/jira/browse/WW-4136 Project: Struts 2 Issue Type: Improvement Components: Example Applications Affects Versions: 2.3.15 Reporter: Rene Gielen Assignee: Rene Gielen Priority: Minor Fix For: 2.3.15.1, 2.3.16 inputPath parameter of FileDownloadAction is not sanitized to avoid accessing WEB-INF directory. Originally reported by Takayoshi isayama of Mitsui Bussan Secure Directions, Inc.. -- 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] [Assigned] (WW-4108) small typo in documentation
[ https://issues.apache.org/jira/browse/WW-4108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen reassigned WW-4108: --- Assignee: Rene Gielen small typo in documentation --- Key: WW-4108 URL: https://issues.apache.org/jira/browse/WW-4108 Project: Struts 2 Issue Type: Improvement Components: Documentation Affects Versions: 2.3.15 Reporter: Jan Li Assignee: Rene Gielen Priority: Trivial Labels: documentation, newbie Fix For: 2.3.16 Attachments: patch.txt in Apache Struts 2 Documentation Home Guides Tag Developers Guide Struts Tags Tag Reference Generic Tag Reference push. it wrote since user is not at the top of the stack should be since user is now at the top of the stack -- 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-4108) small typo in documentation
[ https://issues.apache.org/jira/browse/WW-4108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen closed WW-4108. --- Resolution: Fixed Applied, thanks for reporting small typo in documentation --- Key: WW-4108 URL: https://issues.apache.org/jira/browse/WW-4108 Project: Struts 2 Issue Type: Improvement Components: Documentation Affects Versions: 2.3.15 Reporter: Jan Li Assignee: Rene Gielen Priority: Trivial Labels: documentation, newbie Fix For: 2.3.16 Attachments: patch.txt in Apache Struts 2 Documentation Home Guides Tag Developers Guide Struts Tags Tag Reference Generic Tag Reference push. it wrote since user is not at the top of the stack should be since user is now at the top of the stack -- 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-4093) Javadoc of RegexFieldValidator-annotation out-dated
[
https://issues.apache.org/jira/browse/WW-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen resolved WW-4093.
-
Resolution: Fixed
Assignee: Rene Gielen
Patch applied, thamks
Javadoc of RegexFieldValidator-annotation out-dated
Key: WW-4093
URL: https://issues.apache.org/jira/browse/WW-4093
Project: Struts 2
Issue Type: Bug
Affects Versions: 2.3.14.3
Reporter: Andreas Sachs
Assignee: Rene Gielen
Priority: Minor
Fix For: 2.3.15
Attachments: javadoc_fix1.patch
Hi,
the javadoc documentation of RegexFieldValidator-annotation is wrong:
{noformat}
...
* td class='confluenceTd'expression/td
* td class='confluenceTd'yes/td
* td class='confluenceTd'nbsp;/td
* td class='confluenceTd'The regex to validate the field value
against./td
...
{noformat}
expression should be changed to regex.
All new parameters from the last change are missing in javadoc.
--
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-4093) Javadoc of RegexFieldValidator-annotation out-dated
[
https://issues.apache.org/jira/browse/WW-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen closed WW-4093.
---
Javadoc of RegexFieldValidator-annotation out-dated
Key: WW-4093
URL: https://issues.apache.org/jira/browse/WW-4093
Project: Struts 2
Issue Type: Bug
Affects Versions: 2.3.14.3
Reporter: Andreas Sachs
Assignee: Rene Gielen
Priority: Minor
Fix For: 2.3.15
Attachments: javadoc_fix1.patch
Hi,
the javadoc documentation of RegexFieldValidator-annotation is wrong:
{noformat}
...
* td class='confluenceTd'expression/td
* td class='confluenceTd'yes/td
* td class='confluenceTd'nbsp;/td
* td class='confluenceTd'The regex to validate the field value
against./td
...
{noformat}
expression should be changed to regex.
All new parameters from the last change are missing in javadoc.
--
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-4088) Supressing empty parameters on s:a tag
[
https://issues.apache.org/jira/browse/WW-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671280#comment-13671280
]
Rene Gielen commented on WW-4088:
-
Patches welcom :)
Supressing empty parameters on s:a tag
-
Key: WW-4088
URL: https://issues.apache.org/jira/browse/WW-4088
Project: Struts 2
Issue Type: Improvement
Components: Plugin - Java Templates, Plugin - Tags
Affects Versions: 2.3.14.2
Environment: Tomcat/Centos
Reporter: Greg Huber
Priority: Minor
Fix For: 2.3.16
Hello,
When using the s:a anchor tag you can get parameters with empty values ie
?foo= for null values.
It would be good if there was a way to filter these out, similar to the
struts.xml param name=suppressEmptyParameterstrue/param. The s:if
tags in the body are ignored. I either have to do it in programatically or
use jstl :(
ie possibly do something similar :
from:
{code:xml}
s:a action=eventAdd accesskey=a
s:text name=title.heading.eventadd /
c:if test=${not empty bean.searchString}
s:param name=bean.searchString value=%{bean.searchString} /
/c:if
c:if test=${not empty bean.filter}
s:param name=bean.filter value=%{bean.filter} /
/c:if
s:param name=bean.pageNum value=%{pager.pageNumber} /
/s:a
{code}
To:
{code:xml}
s:a action=eventAdd accesskey=a
s:text name=title.heading.eventadd /
s:param name=bean.searchString value=%{bean.searchString} /
s:param name=bean.filter value=%{bean.filter} /
s:param name=bean.pageNum value=%{pager.pageNumber} /
s:param name=suppressEmptyParameters value=true/
/s:a
{code}
(Ref WW-3920)
Cheers Greg
--
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-4088) Supressing empty parameters on s:a tag
[
https://issues.apache.org/jira/browse/WW-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671279#comment-13671279
]
Rene Gielen commented on WW-4088:
-
Since empty parameters are absolutely valid, this should be a local setting to
the param-Tag rather than some global setting or filter
Supressing empty parameters on s:a tag
-
Key: WW-4088
URL: https://issues.apache.org/jira/browse/WW-4088
Project: Struts 2
Issue Type: Improvement
Components: Plugin - Java Templates, Plugin - Tags
Affects Versions: 2.3.14.2
Environment: Tomcat/Centos
Reporter: Greg Huber
Priority: Minor
Fix For: 2.3.16
Hello,
When using the s:a anchor tag you can get parameters with empty values ie
?foo= for null values.
It would be good if there was a way to filter these out, similar to the
struts.xml param name=suppressEmptyParameterstrue/param. The s:if
tags in the body are ignored. I either have to do it in programatically or
use jstl :(
ie possibly do something similar :
from:
{code:xml}
s:a action=eventAdd accesskey=a
s:text name=title.heading.eventadd /
c:if test=${not empty bean.searchString}
s:param name=bean.searchString value=%{bean.searchString} /
/c:if
c:if test=${not empty bean.filter}
s:param name=bean.filter value=%{bean.filter} /
/c:if
s:param name=bean.pageNum value=%{pager.pageNumber} /
/s:a
{code}
To:
{code:xml}
s:a action=eventAdd accesskey=a
s:text name=title.heading.eventadd /
s:param name=bean.searchString value=%{bean.searchString} /
s:param name=bean.filter value=%{bean.filter} /
s:param name=bean.pageNum value=%{pager.pageNumber} /
s:param name=suppressEmptyParameters value=true/
/s:a
{code}
(Ref WW-3920)
Cheers Greg
--
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] [Comment Edited] (WW-4088) Supressing empty parameters on s:a tag
[
https://issues.apache.org/jira/browse/WW-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671280#comment-13671280
]
Rene Gielen edited comment on WW-4088 at 5/31/13 9:26 AM:
--
Patches welcome :)
was (Author: rgielen):
Patches welcom :)
Supressing empty parameters on s:a tag
-
Key: WW-4088
URL: https://issues.apache.org/jira/browse/WW-4088
Project: Struts 2
Issue Type: Improvement
Components: Plugin - Java Templates, Plugin - Tags
Affects Versions: 2.3.14.2
Environment: Tomcat/Centos
Reporter: Greg Huber
Priority: Minor
Fix For: 2.3.16
Hello,
When using the s:a anchor tag you can get parameters with empty values ie
?foo= for null values.
It would be good if there was a way to filter these out, similar to the
struts.xml param name=suppressEmptyParameterstrue/param. The s:if
tags in the body are ignored. I either have to do it in programatically or
use jstl :(
ie possibly do something similar :
from:
{code:xml}
s:a action=eventAdd accesskey=a
s:text name=title.heading.eventadd /
c:if test=${not empty bean.searchString}
s:param name=bean.searchString value=%{bean.searchString} /
/c:if
c:if test=${not empty bean.filter}
s:param name=bean.filter value=%{bean.filter} /
/c:if
s:param name=bean.pageNum value=%{pager.pageNumber} /
/s:a
{code}
To:
{code:xml}
s:a action=eventAdd accesskey=a
s:text name=title.heading.eventadd /
s:param name=bean.searchString value=%{bean.searchString} /
s:param name=bean.filter value=%{bean.filter} /
s:param name=bean.pageNum value=%{pager.pageNumber} /
s:param name=suppressEmptyParameters value=true/
/s:a
{code}
(Ref WW-3920)
Cheers Greg
--
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-4063) Remote code execution in Struts2 via expression language execution
[ https://issues.apache.org/jira/browse/WW-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen updated WW-4063: Assignee: Rene Gielen Remote code execution in Struts2 via expression language execution -- Key: WW-4063 URL: https://issues.apache.org/jira/browse/WW-4063 Project: Struts 2 Issue Type: Bug Components: Expression Language Affects Versions: 2.3.14 Environment: Mac OS X 10.7 Reporter: Coverity Security Research Laboratory Assignee: Rene Gielen Labels: security Struts2 under certain configurations is vulnerable to remote code execution via the interpretation of EL and OGNL. Since this is I'm assuming a publicly accessible issue, please let me know if I should add a reproducer to this issue or if I should communicate this reproducer though another mechanism. -- 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-4063) Remote code execution in Struts2 via expression language execution
[ https://issues.apache.org/jira/browse/WW-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen updated WW-4063: Affects Version/s: (was: 2.3.14) 2.3.14.1 Remote code execution in Struts2 via expression language execution -- Key: WW-4063 URL: https://issues.apache.org/jira/browse/WW-4063 Project: Struts 2 Issue Type: Bug Components: Expression Language Affects Versions: 2.3.14.1 Environment: Mac OS X 10.7 Reporter: Coverity Security Research Laboratory Assignee: Rene Gielen Labels: security Fix For: 2.3.14.2 Struts2 under certain configurations is vulnerable to remote code execution via the interpretation of EL and OGNL. Since this is I'm assuming a publicly accessible issue, please let me know if I should add a reproducer to this issue or if I should communicate this reproducer though another mechanism. -- 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-4063) Remote code execution in Struts2 via expression language execution
[ https://issues.apache.org/jira/browse/WW-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen updated WW-4063: Fix Version/s: 2.3.14.2 Remote code execution in Struts2 via expression language execution -- Key: WW-4063 URL: https://issues.apache.org/jira/browse/WW-4063 Project: Struts 2 Issue Type: Bug Components: Expression Language Affects Versions: 2.3.14 Environment: Mac OS X 10.7 Reporter: Coverity Security Research Laboratory Assignee: Rene Gielen Labels: security Fix For: 2.3.14.2 Struts2 under certain configurations is vulnerable to remote code execution via the interpretation of EL and OGNL. Since this is I'm assuming a publicly accessible issue, please let me know if I should add a reproducer to this issue or if I should communicate this reproducer though another mechanism. -- 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-4063) Remote code execution in Struts2 via expression language execution
[ https://issues.apache.org/jira/browse/WW-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen closed WW-4063. --- Resolution: Fixed Remote code execution in Struts2 via expression language execution -- Key: WW-4063 URL: https://issues.apache.org/jira/browse/WW-4063 Project: Struts 2 Issue Type: Bug Components: Expression Language Affects Versions: 2.3.14.1 Environment: Mac OS X 10.7 Reporter: Coverity Security Research Laboratory Assignee: Rene Gielen Labels: security Fix For: 2.3.14.2 Struts2 under certain configurations is vulnerable to remote code execution via the interpretation of EL and OGNL. Since this is I'm assuming a publicly accessible issue, please let me know if I should add a reproducer to this issue or if I should communicate this reproducer though another mechanism. -- 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-4063) Remote code execution in Struts2 via expression language execution
[ https://issues.apache.org/jira/browse/WW-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666494#comment-13666494 ] Rene Gielen commented on WW-4063: - The related bulletin is yet undisclosed https://cwiki.apache.org/confluence/display/WW/S2-014 Remote code execution in Struts2 via expression language execution -- Key: WW-4063 URL: https://issues.apache.org/jira/browse/WW-4063 Project: Struts 2 Issue Type: Bug Components: Expression Language Affects Versions: 2.3.14.1 Environment: Mac OS X 10.7 Reporter: Coverity Security Research Laboratory Assignee: Rene Gielen Labels: security Fix For: 2.3.14.2 Struts2 under certain configurations is vulnerable to remote code execution via the interpretation of EL and OGNL. Since this is I'm assuming a publicly accessible issue, please let me know if I should add a reproducer to this issue or if I should communicate this reproducer though another mechanism. -- 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-4063) Remote code execution in Struts2 via expression language execution
[ https://issues.apache.org/jira/browse/WW-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13647339#comment-13647339 ] Rene Gielen commented on WW-4063: - Please contact the Struts security team via email: security at struts.apache.org See also http://struts.apache.org/security.html Remote code execution in Struts2 via expression language execution -- Key: WW-4063 URL: https://issues.apache.org/jira/browse/WW-4063 Project: Struts 2 Issue Type: Bug Components: Expression Language Affects Versions: 2.3.14 Environment: Mac OS X 10.7 Reporter: Coverity Security Research Laboratory Labels: security Struts2 under certain configurations is vulnerable to remote code execution via the interpretation of EL and OGNL. Since this is I'm assuming a publicly accessible issue, please let me know if I should add a reproducer to this issue or if I should communicate this reproducer though another mechanism. -- 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-4058) ContainerHolder causes ThreadLocal memory leak
[
https://issues.apache.org/jira/browse/WW-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641925#comment-13641925
]
Rene Gielen commented on WW-4058:
-
Lukasz, your patch won't work since the ContainerHolder-ThreadLocal is bound
per request thread, while the destroy method is bound to the shutdown thread
which most likely never served a request before. Thus you will not be clearing
the actual request ThreadLocal instances in the destroy phase when calling
clear.
That said, we need to cleanup those ThreadLocals by the end of the request. To
me best candidate seems to be Dispatcher.cleanupRequest. I'm not entirely sure
this gets called no matter what, though. A bit annoying when dealing with
ThreadLocals like these is the lazy initialization via Dispatcher.getContainer,
which has a massive call hierarchy. Usually we would want to have ThreadLocals
initialized with a predictable lifecycle, that is init exactly once at the
beginning and destroy guarantied exactly once at the end of the cycle. Also I'm
wondering if we would better be off to use the Request to store the Container
rather than a ThreadLocal. But I'm not sure about the implication at that stage.
Anyway, to clean up ThreadLocals we should call remove() (since 1.6) rather
than set null. I'm going to change this now as a first step
ContainerHolder causes ThreadLocal memory leak
--
Key: WW-4058
URL: https://issues.apache.org/jira/browse/WW-4058
Project: Struts 2
Issue Type: Bug
Components: Core Actions
Affects Versions: 2.3.14
Environment: Tomcat 7.0.39
java version 1.7.0_15
OpenJDK Runtime Environment (IcedTea7 2.3.7) (7u15-2.3.7-0ubuntu1~12.04.1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
Reporter: Boris Morris
Assignee: Lukasz Lenart
Fix For: 2.3.15
Attachments: hprof_2.png, hprof.png
The localContext ThreadLocal is not cleaned up properly when stopping /
undeploying / redeploying a S2 application. This will in most cases cause the
web application ClassLoader not to be garbage collected, thus leaving a
redeployment memory leak.
I am using Tomcat 7.0.39 and when I undeploy my application the following is
reported in the logs:
{noformat}
2013-04-23 12:00:31,082 [request-worker-4] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application [/dev]
created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal@7f2283e1]) and a value of type
[com.opensymphony.xwork2.inject.ContainerImpl] (value
[com.opensymphony.xwork2.inject.ContainerImpl@330069fc]) but failed to remove
it when the web application was stopped. Threads are going to be renewed over
time to try and avoid a probable memory leak.
2013-04-23 12:00:31,083 [request-worker-4] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application [/dev]
created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal@7f2283e1]) and a value of type
[com.opensymphony.xwork2.inject.ContainerImpl] (value
[com.opensymphony.xwork2.inject.ContainerImpl@330069fc]) but failed to remove
it when the web application was stopped. Threads are going to be renewed over
time to try and avoid a probable memory leak.
2013-04-23 12:00:31,101 [request-worker-4] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application [/dev]
created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal@7f2283e1]) and a value of type
[com.opensymphony.xwork2.inject.ContainerImpl] (value
[com.opensymphony.xwork2.inject.ContainerImpl@330069fc]) but failed to remove
it when the web application was stopped. Threads are going to be renewed over
time to try and avoid a probable memory leak.
2013-04-23 12:00:31,101 [request-worker-4] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application [/dev]
created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal@7f2283e1]) and a value of type
[com.opensymphony.xwork2.inject.ContainerImpl] (value
[com.opensymphony.xwork2.inject.ContainerImpl@330069fc]) but failed to remove
it when the web application was stopped. Threads are going to be renewed over
time to try and avoid a probable memory leak.
2013-04-23 12:00:31,101 [request-worker-4] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application [/dev]
created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal@7f2283e1]) and a value of type
[com.opensymphony.xwork2.inject.ContainerImpl] (value
[com.opensymphony.xwork2.inject.ContainerImpl@330069fc]) but failed to remove
it when the web application was stopped. Threads are going to be renewed over
time to
[jira] [Comment Edited] (WW-4058) ContainerHolder causes ThreadLocal memory leak
[
https://issues.apache.org/jira/browse/WW-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641925#comment-13641925
]
Rene Gielen edited comment on WW-4058 at 4/25/13 4:25 PM:
--
Lukasz, your patch won't work since the ContainerHolder-ThreadLocal is bound
per request thread, while the destroy method is bound to the shutdown thread
which most likely never served a request before. Thus you will not be clearing
the actual request ThreadLocal instances in the destroy phase when calling
clear.
That said, we need to cleanup those ThreadLocals by the end of the request. To
me best candidate seems to be Dispatcher.cleanupRequest. I'm not entirely sure
this gets called no matter what, though. A bit annoying when dealing with
ThreadLocals like these is the lazy initialization via Dispatcher.getContainer,
which has a massive call hierarchy. Usually we would want to have ThreadLocals
initialized with a predictable lifecycle, that is init exactly once at the
beginning and destroy guarantied exactly once at the end of the cycle. Also I'm
wondering if we would better be off to use the Request to store the Container
rather than a ThreadLocal. But I'm not sure about the implication at that stage.
Anyway, to clean up ThreadLocals we should call remove() (since 1.5) rather
than set null. I'm going to change this now as a first yet unimportant step
was (Author: rgielen):
Lukasz, your patch won't work since the ContainerHolder-ThreadLocal is
bound per request thread, while the destroy method is bound to the shutdown
thread which most likely never served a request before. Thus you will not be
clearing the actual request ThreadLocal instances in the destroy phase when
calling clear.
That said, we need to cleanup those ThreadLocals by the end of the request. To
me best candidate seems to be Dispatcher.cleanupRequest. I'm not entirely sure
this gets called no matter what, though. A bit annoying when dealing with
ThreadLocals like these is the lazy initialization via Dispatcher.getContainer,
which has a massive call hierarchy. Usually we would want to have ThreadLocals
initialized with a predictable lifecycle, that is init exactly once at the
beginning and destroy guarantied exactly once at the end of the cycle. Also I'm
wondering if we would better be off to use the Request to store the Container
rather than a ThreadLocal. But I'm not sure about the implication at that stage.
Anyway, to clean up ThreadLocals we should call remove() (since 1.6) rather
than set null. I'm going to change this now as a first step
ContainerHolder causes ThreadLocal memory leak
--
Key: WW-4058
URL: https://issues.apache.org/jira/browse/WW-4058
Project: Struts 2
Issue Type: Bug
Components: Core Actions
Affects Versions: 2.3.14
Environment: Tomcat 7.0.39
java version 1.7.0_15
OpenJDK Runtime Environment (IcedTea7 2.3.7) (7u15-2.3.7-0ubuntu1~12.04.1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
Reporter: Boris Morris
Assignee: Lukasz Lenart
Fix For: 2.3.15
Attachments: hprof_2.png, hprof.png
The localContext ThreadLocal is not cleaned up properly when stopping /
undeploying / redeploying a S2 application. This will in most cases cause the
web application ClassLoader not to be garbage collected, thus leaving a
redeployment memory leak.
I am using Tomcat 7.0.39 and when I undeploy my application the following is
reported in the logs:
{noformat}
2013-04-23 12:00:31,082 [request-worker-4] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application [/dev]
created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal@7f2283e1]) and a value of type
[com.opensymphony.xwork2.inject.ContainerImpl] (value
[com.opensymphony.xwork2.inject.ContainerImpl@330069fc]) but failed to remove
it when the web application was stopped. Threads are going to be renewed over
time to try and avoid a probable memory leak.
2013-04-23 12:00:31,083 [request-worker-4] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application [/dev]
created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal@7f2283e1]) and a value of type
[com.opensymphony.xwork2.inject.ContainerImpl] (value
[com.opensymphony.xwork2.inject.ContainerImpl@330069fc]) but failed to remove
it when the web application was stopped. Threads are going to be renewed over
time to try and avoid a probable memory leak.
2013-04-23 12:00:31,101 [request-worker-4] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application [/dev]
created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[jira] [Commented] (WW-4058) ContainerHolder causes ThreadLocal memory leak
[
https://issues.apache.org/jira/browse/WW-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642044#comment-13642044
]
Rene Gielen commented on WW-4058:
-
The process is as follows: the ThreadLocal Object itself is kind of a container
declared at class instance level (static). It provides access to thread-bound
storage. The crucial part is that all thread bound stored items have to be
removed before the application goes down, because the threads will persist -
these are the request threads from the container thread pool, and they will be
re-used until the container itself is shut down. If by the time of the
application shutdown a single class of the application is still referenced, the
whole classloader doesn't get cleaned up and stays as a zombie in memory.
Removal of a thread-bound object is solely possible within the thread that it
is bound to. Each other thread, including the one performing the application
shutdown, will be able to remove objects from other threads within the
ThreadLocal container.
ContainerHolder causes ThreadLocal memory leak
--
Key: WW-4058
URL: https://issues.apache.org/jira/browse/WW-4058
Project: Struts 2
Issue Type: Bug
Components: Core Actions
Affects Versions: 2.3.14
Environment: Tomcat 7.0.39
java version 1.7.0_15
OpenJDK Runtime Environment (IcedTea7 2.3.7) (7u15-2.3.7-0ubuntu1~12.04.1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
Reporter: Boris Morris
Assignee: Lukasz Lenart
Fix For: 2.3.15
Attachments: hprof_2.png, hprof.png
The localContext ThreadLocal is not cleaned up properly when stopping /
undeploying / redeploying a S2 application. This will in most cases cause the
web application ClassLoader not to be garbage collected, thus leaving a
redeployment memory leak.
I am using Tomcat 7.0.39 and when I undeploy my application the following is
reported in the logs:
{noformat}
2013-04-23 12:00:31,082 [request-worker-4] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application [/dev]
created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal@7f2283e1]) and a value of type
[com.opensymphony.xwork2.inject.ContainerImpl] (value
[com.opensymphony.xwork2.inject.ContainerImpl@330069fc]) but failed to remove
it when the web application was stopped. Threads are going to be renewed over
time to try and avoid a probable memory leak.
2013-04-23 12:00:31,083 [request-worker-4] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application [/dev]
created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal@7f2283e1]) and a value of type
[com.opensymphony.xwork2.inject.ContainerImpl] (value
[com.opensymphony.xwork2.inject.ContainerImpl@330069fc]) but failed to remove
it when the web application was stopped. Threads are going to be renewed over
time to try and avoid a probable memory leak.
2013-04-23 12:00:31,101 [request-worker-4] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application [/dev]
created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal@7f2283e1]) and a value of type
[com.opensymphony.xwork2.inject.ContainerImpl] (value
[com.opensymphony.xwork2.inject.ContainerImpl@330069fc]) but failed to remove
it when the web application was stopped. Threads are going to be renewed over
time to try and avoid a probable memory leak.
2013-04-23 12:00:31,101 [request-worker-4] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application [/dev]
created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal@7f2283e1]) and a value of type
[com.opensymphony.xwork2.inject.ContainerImpl] (value
[com.opensymphony.xwork2.inject.ContainerImpl@330069fc]) but failed to remove
it when the web application was stopped. Threads are going to be renewed over
time to try and avoid a probable memory leak.
2013-04-23 12:00:31,101 [request-worker-4] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application [/dev]
created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal@7f2283e1]) and a value of type
[com.opensymphony.xwork2.inject.ContainerImpl] (value
[com.opensymphony.xwork2.inject.ContainerImpl@330069fc]) but failed to remove
it when the web application was stopped. Threads are going to be renewed over
time to try and avoid a probable memory leak.
2013-04-23 12:00:31,101 [request-worker-4] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application [/dev]
created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal@7f2283e1]) and a value of type
[jira] [Commented] (WW-4054) API docs are missing from the project homepage
[ https://issues.apache.org/jira/browse/WW-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13638843#comment-13638843 ] Rene Gielen commented on WW-4054: - Unbelievably fast solved (before I had a chance to wonder how to solve this :), thanks mate! API docs are missing from the project homepage -- Key: WW-4054 URL: https://issues.apache.org/jira/browse/WW-4054 Project: Struts 2 Issue Type: Bug Components: Documentation Affects Versions: 2.3.14 Reporter: Rene Gielen Assignee: Lukasz Lenart Fix For: 2.3.15 Most probably due to the new site publishing infrastructure, the API docs are missing: http://struts.apache.org/development/2.x/struts2-core/apidocs/index.html -- 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-4054) API docs are missing from the project homepage
Rene Gielen created WW-4054: --- Summary: API docs are missing from the project homepage Key: WW-4054 URL: https://issues.apache.org/jira/browse/WW-4054 Project: Struts 2 Issue Type: Bug Components: Documentation Affects Versions: 2.3.14 Reporter: Rene Gielen Most probably due to the new site publishing infrastructure, the API docs are missing: http://struts.apache.org/development/2.x/struts2-core/apidocs/index.html -- 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-4018) Revert parse param back
[
https://issues.apache.org/jira/browse/WW-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605791#comment-13605791
]
Rene Gielen commented on WW-4018:
-
The parse attribute looks redundant to me, the ${} syntax makes it clearly an
expression
Revert parse param back
---
Key: WW-4018
URL: https://issues.apache.org/jira/browse/WW-4018
Project: Struts 2
Issue Type: Sub-task
Components: XML Validators
Affects Versions: 2.3.12
Reporter: Lukasz Lenart
Priority: Minor
Fix For: 2.3.13
Maybe it is a better solution instead having bunch of additional params to
keep expressions.
{code:java}
@IntRangeFieldValidator(message = Default message, key = i18n.key,
shortCircuit = true, min = 0, max = 42)
@IntRangeFieldValidator(message = Default message, key = i18n.key,
shortCircuit = true, min = ${minValue}, max = ${maxValue} parse=true)
{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] [Commented] (WW-4016) Rename validatorType to validatorName
[
https://issues.apache.org/jira/browse/WW-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605797#comment-13605797
]
Rene Gielen commented on WW-4016:
-
As a really breaking change, 3.0 target version looks fine
Rename validatorType to validatorName
-
Key: WW-4016
URL: https://issues.apache.org/jira/browse/WW-4016
Project: Struts 2
Issue Type: Improvement
Components: XML Validators
Affects Versions: 2.3.12
Reporter: Lukasz Lenart
Priority: Minor
Fix For: 3.0
Attachments: WW-4016.patch
Right no validatorType is a simple String in
AnnotationValidationConfigurationBuilder which can lead to mistakes.
{code:java}
String validatorType = regex;
{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] [Commented] (WW-3924) refactor file upload framework
[ https://issues.apache.org/jira/browse/WW-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13534786#comment-13534786 ] Rene Gielen commented on WW-3924: - Uhm - sorry guys, but so far this looks not like what we discussed in the list. AFACIS we talked about providing non breaking API extensions to support multipart handler plugins a plugin. It was explicitely not about changing core to use some new library, even not if it is marked optional. Some more concrete stuff regarding the patch - Please provide a pure patch. Roughly two third of this patch is reformatted original code. Please keep your IDE from automatic reformatting. A patch / commit is either functional or reformatting the code, but not both - please tidy up your code. Things like IDEA standard file template comments or commented out code should not go into a patch. Best example is FastUploadMultiPartHandler, which includes a wrong JavaDoc-comment and code in comments. - Again FastUploadMultiPartHandler: Please use one file for one class, as long you are not creating inner classes. This java-File contains two toplevel classes - Please be sure to review your code for general quality. As I understood, you are using IntelliJ IDEA. Reviewing warnings would easily have revealed that in NgFileUploadInterceptor:182 there is a senseless null check due to NPE about to happen before in line 176ff. Also you might want to review Dispatcher#cleanUpRequest, just to name another one - DispatcherTest#testConfigurationManager - what is this URL, split into two lines, one now marking a Java label? That was just a quick first review. A cleaner patch helps reviewing by far... Now regarding the API changes - NG as naming component is a bit unfortunate. What comes in two years, when we have even better ideas? NNG? :) - As I see it, a new API for MultiPart should either be extending the old or providing a full new implementation if you flip the switch. Full means full alternative, that is: it should provide an implementation of the former functionality. Only then it is possible to deprecate the old API and declare the new stuff as API to use. What I see here is having just two APIs, one for commons-fu etc and one for fastupload. An API change proposal should - check wether the old API can be reused, starting with factoring out more general interfaces and more abstract classes in the hierarchy. Did that happen? - if extending the old doesn't work, provide a complete implemetation for the former functionality. That is, implement a commons-fu Provider For the integration of fastupload itself: This library and related implementations will not make it into core any time soon, as it would not for other new libs. You are providing an implementation alternative. Fine. That's what plugis are for. So if a new MultiPart API makes it into the distribution, feel free to provide a plugin, maybe as part of your library distribution. A small tip: even if we would want to include the lib into our distro, we couldn't. You don't provide any license. To make it into any Apache related distro, a library must be released under a APL compatible license. To get adoption at all, your lib should generally be released under an accepted OSS license. refactor file upload framework -- Key: WW-3924 URL: https://issues.apache.org/jira/browse/WW-3924 Project: Struts 2 Issue Type: Improvement Components: New API, Integration Affects Versions: 2.3.7 Environment: HTTP, RFC 1867, form-based upload. Reporter: Link Qian Labels: features, patch Fix For: 2.3.9 Attachments: fileupload-patch.txt Original Estimate: 504h Remaining Estimate: 504h refactor current file upload framework in Struts2, the goals are: 1, compatible with current file upload API in Struts2. 2, enable file upload framework to integration with form-based upload components easily. 3, enable user to use stream/memory parsing model beyond temporary file parsing model. 4, testing -- 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-3930) Cannot access plugin (.jar) static resources via /struts or /static URL
[ https://issues.apache.org/jira/browse/WW-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen updated WW-3930: Priority: Minor (was: Blocker) Cannot access plugin (.jar) static resources via /struts or /static URL --- Key: WW-3930 URL: https://issues.apache.org/jira/browse/WW-3930 Project: Struts 2 Issue Type: Bug Components: Dispatch Filter Affects Versions: 2.3.7 Environment: Struts 2.3.7 Reporter: Yoseph Stephen Priority: Minor Labels: plugin, resource, static I try creating a simple plugin (guided by http://struts.apache.org/2.3.7/docs/plugins.html) with the following structure: - src -- com --- test TestAction.java -- WEB-INF --- content hello.vm -- static --- test.js -- struts-plugin.xml Everything works fine (action can be accessed), except I cannot access the static resources using URL: http://host/app_context/static/test.js. I have also tried the struts/test.js url, it doesn't work either (shows 404 page). I have also set the struts.serve.static constant to true. I have checked the plugin .jar contains the static folder and the test.js file in it. Need fix ASAP. Thx -- 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-3876) NumberConverter convert WRONG
[
https://issues.apache.org/jira/browse/WW-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13452805#comment-13452805
]
Rene Gielen commented on WW-3876:
-
Number formats are locale specific. 1,000.00 is a valid representation for 1000
in US, while in most European countries it would be 1.000,00. To learn more
about that, check the NumberFormat JDK API docs.
NumberConverter convert WRONG
-
Key: WW-3876
URL: https://issues.apache.org/jira/browse/WW-3876
Project: Struts 2
Issue Type: Bug
Components: Core Actions, Value Stack
Affects Versions: 2.3.4.1
Environment: java version 1.6.0_31
Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
OS:Win7
Browser:Chrome
OGNL version 3.0.5
Reporter: Steven Sinclair
Labels: mapping
I have one action let's called Foo.
Foo has one field named entity and Foo implement ModelDriven interface.
so code like below：
{code:title=Foo.java|borderStyle=dashed}
@Namespace(/userresourceaccount)
public class Foo ... {
private UserResourceAccount entity = new UserResourceAccount();
@Override
public UserResourceAccount getModel() {
return entity;
}
@Action(value = deleteResourceAccountByUserId, results = {@Result(name
= swJson, type = json, params = {
root, result})})
public String deleteResourceAccountByUserId()
throws Exception {
try {
String id = RequestUtils.getStringParameter(getRequest(), id);
String[] ids = id.split(,);
userResourceAccountService.deleteUserResourceAccount(ids);
result.add(true);
}
catch (Exception e) {
logger.error(e.getMessage(), e);
result.add(false);
}
return swJson;
}
...
{code}
http request like this
{color:green}/userresourceaccount/deleteResourceAccountByUserId.action?id=3571,{color}
actually,above id is not numerical.it is String value.
but entity has one Long field named id:
{code:title=UserResourceAccount.java|borderStyle=dashed}
public class UserResourceAccount {
private Long id;
...
}
{code}
and error happened.
{quote}
2012-09-10 18:24:53,258 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Checking ConfigurationProviders for reload.
2012-09-10 18:24:53,261 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Entering nullPropertyValue
[target=[com.opensymphony.xwork2.DefaultTextProvider@1071776],
property=struts]
2012-09-10 18:24:53,262 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Checking ConfigurationProviders for reload.
2012-09-10 18:24:53,264 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Entering nullPropertyValue
[target=[com.opensymphony.xwork2.DefaultTextProvider@1071776],
property=struts]
2012-09-10 18:24:53,265 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Checking ConfigurationProviders for reload.
2012-09-10 18:24:53,266 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Creating an DefaultActionProxy for namespace /userresourceaccount and
action name deleteResourceAccountByUserId
2012-09-10 18:24:53,268 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- entering MessageStoreInterceptor ...
2012-09-10 18:24:53,269 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- retrieve error / message from session to populate into action
[net.bwda.framework.web.asset.UserResourceAccountAction@134b16b]
2012-09-10 18:24:53,269 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- intercept '/userresourceaccount/deleteResourceAccountByUserId' {
2012-09-10 18:24:53,269 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- applied invocation context locale=zh_CN
2012-09-10 18:24:53,270 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- before Locale=zh_CN
2012-09-10 18:24:53,270 [5119480@qtp-29553921-9] DEBUG
[jira] [Updated] (WW-3876) NumberConverter convert WRONG
[
https://issues.apache.org/jira/browse/WW-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen updated WW-3876:
Priority: Minor (was: Major)
NumberConverter convert WRONG
-
Key: WW-3876
URL: https://issues.apache.org/jira/browse/WW-3876
Project: Struts 2
Issue Type: Bug
Components: Core Actions, Value Stack
Affects Versions: 2.3.4.1
Environment: java version 1.6.0_31
Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
OS:Win7
Browser:Chrome
OGNL version 3.0.5
Reporter: Steven Sinclair
Priority: Minor
Labels: mapping
I have one action let's called Foo.
Foo has one field named entity and Foo implement ModelDriven interface.
so code like below：
{code:title=Foo.java|borderStyle=dashed}
@Namespace(/userresourceaccount)
public class Foo ... {
private UserResourceAccount entity = new UserResourceAccount();
@Override
public UserResourceAccount getModel() {
return entity;
}
@Action(value = deleteResourceAccountByUserId, results = {@Result(name
= swJson, type = json, params = {
root, result})})
public String deleteResourceAccountByUserId()
throws Exception {
try {
String id = RequestUtils.getStringParameter(getRequest(), id);
String[] ids = id.split(,);
userResourceAccountService.deleteUserResourceAccount(ids);
result.add(true);
}
catch (Exception e) {
logger.error(e.getMessage(), e);
result.add(false);
}
return swJson;
}
...
{code}
http request like this
{color:green}/userresourceaccount/deleteResourceAccountByUserId.action?id=3571,{color}
actually,above id is not numerical.it is String value.
but entity has one Long field named id:
{code:title=UserResourceAccount.java|borderStyle=dashed}
public class UserResourceAccount {
private Long id;
...
}
{code}
and error happened.
{quote}
2012-09-10 18:24:53,258 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Checking ConfigurationProviders for reload.
2012-09-10 18:24:53,261 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Entering nullPropertyValue
[target=[com.opensymphony.xwork2.DefaultTextProvider@1071776],
property=struts]
2012-09-10 18:24:53,262 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Checking ConfigurationProviders for reload.
2012-09-10 18:24:53,264 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Entering nullPropertyValue
[target=[com.opensymphony.xwork2.DefaultTextProvider@1071776],
property=struts]
2012-09-10 18:24:53,265 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Checking ConfigurationProviders for reload.
2012-09-10 18:24:53,266 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Creating an DefaultActionProxy for namespace /userresourceaccount and
action name deleteResourceAccountByUserId
2012-09-10 18:24:53,268 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- entering MessageStoreInterceptor ...
2012-09-10 18:24:53,269 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- retrieve error / message from session to populate into action
[net.bwda.framework.web.asset.UserResourceAccountAction@134b16b]
2012-09-10 18:24:53,269 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- intercept '/userresourceaccount/deleteResourceAccountByUserId' {
2012-09-10 18:24:53,269 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- applied invocation context locale=zh_CN
2012-09-10 18:24:53,270 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- before Locale=zh_CN
2012-09-10 18:24:53,270 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Setting params id = [ 3571, ]
2012-09-10 18:24:53,271 [5119480@qtp-29553921-9] DEBUG
[jira] [Closed] (WW-3876) NumberConverter convert WRONG
[
https://issues.apache.org/jira/browse/WW-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Gielen closed WW-3876.
---
Resolution: Not A Problem
As pointed out in the comments, Struts 2 behaves correctly here
NumberConverter convert WRONG
-
Key: WW-3876
URL: https://issues.apache.org/jira/browse/WW-3876
Project: Struts 2
Issue Type: Bug
Components: Core Actions, Value Stack
Affects Versions: 2.3.4.1
Environment: java version 1.6.0_31
Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
OS:Win7
Browser:Chrome
OGNL version 3.0.5
Reporter: Steven Sinclair
Priority: Minor
Labels: mapping
I have one action let's called Foo.
Foo has one field named entity and Foo implement ModelDriven interface.
so code like below：
{code:title=Foo.java|borderStyle=dashed}
@Namespace(/userresourceaccount)
public class Foo ... {
private UserResourceAccount entity = new UserResourceAccount();
@Override
public UserResourceAccount getModel() {
return entity;
}
@Action(value = deleteResourceAccountByUserId, results = {@Result(name
= swJson, type = json, params = {
root, result})})
public String deleteResourceAccountByUserId()
throws Exception {
try {
String id = RequestUtils.getStringParameter(getRequest(), id);
String[] ids = id.split(,);
userResourceAccountService.deleteUserResourceAccount(ids);
result.add(true);
}
catch (Exception e) {
logger.error(e.getMessage(), e);
result.add(false);
}
return swJson;
}
...
{code}
http request like this
{color:green}/userresourceaccount/deleteResourceAccountByUserId.action?id=3571,{color}
actually,above id is not numerical.it is String value.
but entity has one Long field named id:
{code:title=UserResourceAccount.java|borderStyle=dashed}
public class UserResourceAccount {
private Long id;
...
}
{code}
and error happened.
{quote}
2012-09-10 18:24:53,258 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Checking ConfigurationProviders for reload.
2012-09-10 18:24:53,261 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Entering nullPropertyValue
[target=[com.opensymphony.xwork2.DefaultTextProvider@1071776],
property=struts]
2012-09-10 18:24:53,262 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Checking ConfigurationProviders for reload.
2012-09-10 18:24:53,264 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Entering nullPropertyValue
[target=[com.opensymphony.xwork2.DefaultTextProvider@1071776],
property=struts]
2012-09-10 18:24:53,265 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Checking ConfigurationProviders for reload.
2012-09-10 18:24:53,266 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Creating an DefaultActionProxy for namespace /userresourceaccount and
action name deleteResourceAccountByUserId
2012-09-10 18:24:53,268 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- entering MessageStoreInterceptor ...
2012-09-10 18:24:53,269 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- retrieve error / message from session to populate into action
[net.bwda.framework.web.asset.UserResourceAccountAction@134b16b]
2012-09-10 18:24:53,269 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- intercept '/userresourceaccount/deleteResourceAccountByUserId' {
2012-09-10 18:24:53,269 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- applied invocation context locale=zh_CN
2012-09-10 18:24:53,270 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- before Locale=zh_CN
2012-09-10 18:24:53,270 [5119480@qtp-29553921-9] DEBUG
[com.opensymphony.xwork2.util.logging.commons.CommonsLogger.debug(CommonsLogger.java:68)]
- Setting params id = [ 3571, ]
2012-09-10 18:24:53,271
[jira] [Created] (WW-3858) Decouple token names from their respective session attribute names
Rene Gielen created WW-3858: --- Summary: Decouple token names from their respective session attribute names Key: WW-3858 URL: https://issues.apache.org/jira/browse/WW-3858 Project: Struts 2 Issue Type: Improvement Components: Core Interceptors Affects Versions: 2.3.4 Reporter: Rene Gielen Assignee: Rene Gielen Fix For: 2.3.5 Currently token names are used as is to store session attributes for later token check. By namespacing session attributes security can be improved. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WW-3860) Restrict accepted parameter name length
Rene Gielen created WW-3860: --- Summary: Restrict accepted parameter name length Key: WW-3860 URL: https://issues.apache.org/jira/browse/WW-3860 Project: Struts 2 Issue Type: Improvement Components: Core Interceptors Affects Versions: 2.3.4 Reporter: Rene Gielen Assignee: Rene Gielen Fix For: 2.3.5 Long parameter names are costly to evaluate for OGNL and should be limited to a reasonable length, in our case 100 characters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WW-3858) Decouple token names from their respective session attribute names
[ https://issues.apache.org/jira/browse/WW-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen resolved WW-3858. - Resolution: Fixed Fix Version/s: (was: 2.3.5) 2.3.4.1 Token names are now prefixed. Decouple token names from their respective session attribute names -- Key: WW-3858 URL: https://issues.apache.org/jira/browse/WW-3858 Project: Struts 2 Issue Type: Improvement Components: Core Interceptors Affects Versions: 2.3.4 Reporter: Rene Gielen Assignee: Rene Gielen Fix For: 2.3.4.1 Currently token names are used as is to store session attributes for later token check. By namespacing session attributes security can be improved. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WW-3860) Restrict accepted parameter name length
[ https://issues.apache.org/jira/browse/WW-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen resolved WW-3860. - Resolution: Fixed Fix Version/s: (was: 2.3.5) 2.3.4.1 Johno's patch applied. Restrict accepted parameter name length --- Key: WW-3860 URL: https://issues.apache.org/jira/browse/WW-3860 Project: Struts 2 Issue Type: Improvement Components: Core Interceptors Affects Versions: 2.3.4 Reporter: Rene Gielen Assignee: Rene Gielen Fix For: 2.3.4.1 Long parameter names are costly to evaluate for OGNL and should be limited to a reasonable length, in our case 100 characters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
