[
https://issues.apache.org/jira/browse/WW-5733?focusedWorklogId=1041105&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1041105
]
ASF GitHub Bot logged work on WW-5733:
--------------------------------------
Author: ASF GitHub Bot
Created on: 12/Sep/26 10:08
Start Date: 12/Sep/26 10:08
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1923:
URL: https://github.com/apache/struts/pull/1923
Fixes [WW-5733](https://issues.apache.org/jira/browse/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](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1041105)
Remaining Estimate: 0h
Time Spent: 10m
> JasperReports 7 exporter providers close the response stream before the
> report is written — empty response on Tomcat
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WW-5733
> URL: https://issues.apache.org/jira/browse/WW-5733
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - JasperReports
> Reporter: Lukasz Lenart
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 7.4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Every {{JasperReport7*ExporterProvider.createExporter}} in
> {{struts2-jasperreports7-plugin}} (CSV, HTML, PDF, RTF, XML, XLSX) wires the
> exporter output like this:
> {code:java}try (OutputStream responseStream = response.getOutputStream()) {
> exporter.setExporterOutput(new
> SimpleWriterExporterOutput(responseStream));
> }
> {code}
> The try-with-resources closes the servlet output stream when
> {{createExporter}} returns. Only afterwards does
> {{JasperReport7Result.exportReport}} call {{exporter.exportReport()}} and
> {{response.getOutputStream().flush()}}, so the whole report is written to an
> already closed stream.
> On Tomcat, {{ServletOutputStream.close()}} commits the response with the
> bytes written so far, which is none, and discards every later write.
> Reproduced with an embedded Tomcat 10.1.34 and a servlet performing the same
> sequence (close inside try-with-resources, then write, then flush):
> {code}/good -> status=200 content-length=(none) body=28 bytes
> /bad -> status=200 content-length=0 body=0 bytes
> {code}
> So on Tomcat the plugin returns an empty {{200}} with {{Content-Length: 0}}
> for every format. {{JasperReport7ResultTest}} does not catch it because
> Spring's {{MockHttpServletResponse}} keeps accepting writes after {{close()}}.
> The 6.x {{struts2-jasperreports-plugin}} is unaffected:
> {{JasperReportsResult}} exports into a {{ByteArrayOutputStream}}, sets
> {{Content-Length}}, then writes and closes.
> Fix: obtain {{response.getOutputStream()}} without try-with-resources in all
> six providers (the {{IOException}} is still wrapped into
> {{StrutsException}}), keep streaming directly to the response, and leave
> flushing to {{JasperReport7Result}} and closing to the container. Guard it
> with a test that runs the result against an {{HttpServletResponseWrapper}}
> whose {{ServletOutputStream}} rejects writes after {{close()}}, which is the
> semantics the mock lacks.
> Affects every release since 7.1.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
