The story behind ReportShell
When people hear “report”, they often picture a static PDF on someone's desk.
But a report can be just a data-driven page: often parameterized, sometimes interactive, and frequently composed of tables, charts, images, logos, branding and totals. Exporting to PDF or Excel is usually part of the requirement, but that is just an output format, not the reporting itself.
Almost every serious web app eventually needs pages like this. ReportShell™ builds on JasperReports® Library as the reporting engine, and helps you turn your reports into a first-class web feature, so any Spring app can ship them quickly and securely.
[Trademark Note]: JasperReports® is a trademark or registered trademark of Cloud Software Group, Inc and/or its subsidiaries. ReportShell is not affiliated with, endorsed by, sponsored by, or otherwise associated with the owner of the JasperReports® mark. See footer for full trademark disclaimer.
Reporting engines are often introduced as tools for producing printable documents, but JasperReports Library is also a query execution engine and HTML renderer. Each report carries its own metadata, parameters, queries, and layout, all wrapped behind a single declarative definition.
That makes it a pragmatic way to render summary pages, statistics views, listings, and other data-driven screens without building each one as a custom page. You define the data, parameters, and layout once, and you get a previewable, exportable, parameterized view that fits naturally inside your application, with professional PDF output when you need it. Not an HTML-to-PDF dump, but a polished export produced by the reporting engine itself.
ReportShell turns those capabilities into a first-class web feature: REST APIs for parameter forms, persistent executions and exports, a frontend report viewer, cascading input controls, and extension points for access control, fill and export flows. The goal is simple: make it cheap enough to add a polished data-driven page that you stop reaching for a custom screen by default.
ReportShell grew out of a real product need at Bivektor. We were building a financial analysis application where the customer needed new data-driven pages on a regular basis, often as analysts requested them. Fully custom interactive pages were not the right answer. They looked polished, but each one took too much time to design, review, and ship for what was usually a parameterized query with a structured layout and a PDF export.
SaaS reporting platforms were not a fit either. The application had to run on the customer's own servers, inside their existing Java stack, behind their authentication, alongside the rest of the product.
We had used JasperReports, BIRT, Apache POI and Aspose before, mostly in the traditional reporting model: generate a document, deliver it to the user. This case was different. We needed pages that felt native to the application, with proper forms, previews, exports, permissions and stable URLs. That gap, between a classic reporting server and a hand-built web page, is what ReportShell was designed to fill.
Apps often don't start out with “reports” on the roadmap. It starts with one page: a customer summary, an order breakdown, an analytics view. Then a second one. Then three more. Then someone asks for a clean PDF export, and another team asks for Word or Excel. The pattern repeats across internal tools, SaaS products, line-of-business apps, customer portals, anything with structured data and users who need to share or print it.
Two things tend to slow these teams down:
It is fair to note that reporting engines have trade-offs in their HTML output. Because the same report definition has to render consistently to PDF and other paginated formats, you typically won't get arbitrary modern CSS layouts, fluid responsive breakpoints, or fully custom HTML/CSS designs. The scope here is, summary and report-like data-driven pages with tables, charts, totals where the focus is on the data and how to filter and interact with it.
ReportShell exists for that exact gap.
In the beginning, our integration layer was small. One application, a handful of reports, simple parameters. JasperReports Library handled most of the work. Over time the requirements grew: calendars that excluded weekends and holidays, default values for input controls, cascading parameters for dependent dropdowns, additional data sources, report-specific behavior and security.
Eventually the integration layer was no longer just glue code. It had become the part of the system where the important application-level decisions lived: how a report is described, executed, secured, cached, exported, and rendered inside a web application.
When we needed the same capabilities across other products, the next step was clear. We turned that work into ReportShell: a reusable product built with well-designed layers, a flexible API, and first-class Spring Boot integration, so it can be embedded cleanly into almost any customer application.
For a handful of reports, you can absolutely hardcode the decisions: branch on the report identifier, wire each one up by hand, embed format choices and parameter handling directly in the code. That works, until it doesn't. Once the list of reports grows, or the same patterns need to repeat across multiple apps, those ad-hoc branches become the slowest part of shipping a new page.
A capable team can build a project-specific reporting layer for one app. The harder part is turning that into something reliable, reusable, extensible, documented, and easy to carry into the next product. That is where ReportShell is focused.
It packages the application-level pieces around embedded reporting: report resolution, parameter binding, input controls, execution flow, previews, exports, viewer integration, and extension points. A production-ready reporting layer also has to handle content negotiation, standardized error responses, locale and timezone awareness, exporter customization, data source resolution, and security boundaries around storage and execution. Instead of spending weeks or months on that foundation, a Spring team can add it as a lightweight application feature.
Team members can build and ship common reports through ReportShell's higher-level APIs without deep knowledge of the JasperReports Library. That expertise still matters where it should: complex reports and queries, performance optimization, scriptlets, and fill or export customization.
If your product is a dedicated reporting platform with a very specific scope, you may still build deeply customized infrastructure yourself. But for most applications, where data-driven report-like pages and professional exports are one valuable capability among many, ReportShell removes a large amount of undifferentiated work. Once the integration cost is out of the way, it becomes one of the fastest ways to ship secure, professional, data-driven views inside a web application.
One Spring Boot starter and a repository of reports is all you need to get started.
Get Started