WW-5733 fix(jasperreports7): stop closing the response stream before the report is written

[lukaszlenart]

Fixes WW-5733

What

Every JasperReport7*ExporterProvider.createExporter obtained the servlet output stream in a try-with-resources block, so the stream was closed as soon as the method returned — before JasperReport7Result.exportReport called exporter.exportReport(). Tomcat commits the response on close() with the bytes written so far (none) and discards everything written afterwards, so every export from this plugin was an empty 200 with Content-Length: 0 — CSV, PDF, HTML, RTF, XML and XLSX alike, since 7.1.0. The unit tests never noticed because Spring's MockHttpServletResponse keeps accepting writes after close().

Reproduced on embedded Tomcat 10.1.34 with a servlet doing the same sequence (close in try-with-resources → write → flush): status=200 content-length=0 body=0 bytes; the same servlet without the close delivers the payload.

Fix

The six providers now hand the open stream to the exporter and leave it alone. JasperReport7Result still flushes after exporting; the container closes the stream at the end of the request, which is the normal servlet idiom. JasperReports' OutputStream-based exporter outputs do not close the stream either (toClose = false), so there is no double close. The 6.x plugin is unaffected — it buffers into a ByteArrayOutputStream and closes after writing.

Test

testExportWritesNothingAfterClosingTheResponseStream runs the result for all six formats against an HttpServletResponseWrapper whose ServletOutputStream rejects writes after close() — the container semantics the mock lacks. Before the fix it fails on the first format with IOException: Stream closed.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud