WW-3245 feat(jasperreports): fill from report parameters when no dataSource or connection is set - #1919
Merged
Merged
Conversation
…Source or connection is set Both result types insisted on either dataSource or connection and only ever called the three-argument JasperFillManager.fillReport overloads, so a report whose data comes from a JasperReports query executer (Hibernate, CSV, JSON, EJBQL, ...) could not be filled without first materialising a List in the action. When neither is configured the result now calls fillReport(report, params) and lets JasperReports resolve the data from the parameter map exactly as its standalone API does: the executer's supplier object (HIBERNATE_SESSION, CSV_INPUT_STREAM, ...) or a ready REPORT_DATA_SOURCE / REPORT_CONNECTION is handed over via reportParameters. No parameter-key inspection and no new dependency, so every present and future executer works the same way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
lukaszlenart
marked this pull request as ready for review
September 12, 2026 08:54
lukaszlenart
added a commit
to apache/struts-site
that referenced
this pull request
Sep 12, 2026
…330) Companion to apache/struts#1919: dataSource is no longer required, and a report can be filled from its parameters alone (HIBERNATE_SESSION, CSV_INPUT_STREAM, REPORT_DATA_SOURCE, ...) when neither dataSource nor connection is set. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes WW-3245
What
Both JasperReports result types (
jasperreportsandjasperreports7plugins) required eitherdataSourceorconnectionand only ever called the three-argumentJasperFillManager.fillReportoverloads. A report whose data comes from a JasperReports query executer — Hibernate (HIBERNATE_SESSION), CSV, JSON, EJBQL, XPath… — could therefore not be filled without first materialising aListin the action, which is what the ticket (2009) asks to remove.When neither is configured, the result now calls
fillReport(report, parameters)and lets JasperReports resolve its data from the parameter map exactly as its standalone API does. The supplier object the executer expects, or a readyREPORT_DATA_SOURCE/REPORT_CONNECTION, is handed over viareportParameters.Why this shape and not the attached patch
The 2009 patch special-cased
HIBERNATE_SESSIONand importedJRHibernateQueryExecuterFactory. JasperReports 7 moved that class out of the core jar into the optionaljasperreports-hibernateartifact, so the patch would not compile against the jasperreports7 plugin, and every other executer would still be locked out. Delegating to the two-argument overload needs no key inspection and no new dependency, and works for every present and future executer.Precedence is unchanged:
connection→dataSource→ parameters-only. The acceptance checks on thedataSourceandreportParametersexpressions still run whenever they are set. When the parameter map carries nothing the executer can use, the outcome is JasperReports' own (the JDBC executer logs and fills perwhenNoDataType, Hibernate throws) — the plugin adds no policy of its own; a debug line marks the parameters-only path so a forgottendataSourcestays diagnosable.Tests
One new test per plugin,
testFillFromReportParametersWithoutDataSourceOrConnection: acsv.jrxmlfixture with acsvquery and nodataSource/connectionon the result,CSV_INPUT_STREAMsupplied viareportParameters, XML export asserted to contain the CSV row. Both failed withNo dataSource specified...before the change.Docs: companion struts-site PR follows.
🤖 Generated with Claude Code