[
https://issues.apache.org/jira/browse/WW-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-5734:
------------------------------
Priority: Trivial (was: Major)
> Run the JasperReports 7 plugin end-to-end on an embedded Tomcat in its test
> suite
> ---------------------------------------------------------------------------------
>
> Key: WW-5734
> URL: https://issues.apache.org/jira/browse/WW-5734
> Project: Struts 2
> Issue Type: Task
> Components: Plugin - JasperReports
> Reporter: Lukasz Lenart
> Priority: Trivial
> Fix For: 7.4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{struts2-jasperreports7-plugin}} shipped in 7.1.0 and has never been
> exercised end-to-end: no sample application uses it, and its unit tests drive
> {{JasperReport7Result}} against Spring's {{MockHttpServletResponse}}, which
> does not model container behaviour. That is how WW-5731 (single-line CSV),
> WW-5732 (case-sensitive format lookup) and WW-5733 (every export an empty
> {{200}} on Tomcat) went unnoticed for four minor releases.
> Adding the plugin to the showcase is not an option: JasperReports is LGPL
> (ASF Category X) and the showcase WAR is part of the release assembly — the
> previous showcase example was removed for exactly that reason in 2006.
> Add an integration test to the plugin module instead: boot Struts on
> {{tomcat-embed-core}} (test scope, so the LGPL dependency is not
> distributed), configure a package extending {{jasperreports7-default}} with
> an action returning a {{jasperReport7}} result over a compiled {{.jrxml}},
> and assert that a real HTTP request returns a non-empty body of the expected
> content type for each bundled format. The test stays in the module's surefire
> run so CI exercises the plugin on every build.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
