milgner/jasper-render

Provides a HTTP interface to render JasperReports from non-JVM projects

Hi there 👋, I'm Marcus

an all-round IT professional who loves solving diverse and complex problems

• 💻 My expertise spans a broad range from 3D games to data processing and IoT projects

• 🔬 In my free time I learn new technologies by working on pet projects. I built a digital Shadowrun 6 character sheet to learn VueJS and a complexity poker app to experiment with Rust and Svelte.

• 🔐 I also built and am still extending keedrop.com, a tool that helps you to avoid posting passwords via plain-text chat

• ⌨ On top of that, I like contributing to open-source software to improve the overall quality of digital ecosystem

My preferred languages & tech stack components:

jasper-render's Issues

Generate fonts extension properties

As a user, I want to add TrueType fonts into the fonts directory and automatically use them in my reports.

It needs to generate a .properties file as described in http://jasperreports.sourceforge.net/sample.reference/fonts/

Docker support

It might be useful to add a Dockerfile that builds a container image with all reports, fonts etc and that can be easily deployed.

Details will have to be eked out. It could statically generate the fonts extension as described in #8, too.

Report versioning

Over time a report might evolve and receive new properties, fields or rename any of these.

For this, it would be useful to support multiple versions of one report.
Exact requirements & API still TBD.

Authentication Support

It should be possible to check whether the client is authorized to render reports.
It could be either a fixed, pre-shared token or a JWT for which the public signing key is set up in the configuration.

Add request validation

This is a possible approach:

• check the existence of the report name and return 404 if not found
• check the JSON so that it
  • contains the report name as top-level key
  • contains a key for all report parameters that don't have a defaultValueExpression set
  • contains an Items key (even if it might be an empty array)
  • does not contain any other keys that can't be mapped to a report property
  • return 422 if any of these conditions aren't met
• check the existence of the letterhead, if specified, return 404 if not found

API to upload new reports & report versions

Might be nice, but I'm not sure whether it's required or whether it just creates potential for unexpected behaviour. If the report structure changes with the new upload, it might result in other clients that are trying to process a request while the upload is happening unable to handle the render.

This would require versioning first. See #13

Batch rendering support

It might be useful to render different reports in a batch, returning a concatenated PDF from all reports.
In that case, instead of receiving a simple JSON object in the form of

{
  "reportName": {}
}

which is sent to /render/:reportName, it would receive

[
  {
    "reportName": {}
  },
  {
    "anotherReportName": {}
  }
]

to a separate /renderBatch endpoint.