Docmosis in Java Setup: License Key, LibreOffice, Security

Before a Java service can turn a Docmosis template into a PDF, it needs a jar that Maven Central does not carry, a license key the core accepts and a LibreOffice converter on a host it can reach. All three apply to Docmosis-Java 4.9.1, the current embedded library from May 2026, so they come first here, ahead of the advisories and the PDF/A ceiling. Where the library would run we show its output, and otherwise we name the public record behind the claim, whether the vendor's documentation and release notes, NVD, LibreOffice's advisories, GitHub or Maven Central.

We work at Iron Software, and the end of this article covers our library, IronPDF.

Installing the Jar Without Maven Central

The com.docmosis group on Maven Central holds three Docmosis Cloud SDKs and no Docmosis-Java artifact, so the 4.9.1 jar comes out of the vendor's zip and goes into a local repository with mvn install:install-file. This introduction to Maven explains what a POM file declares, and the POM is where this install can go wrong. Run with the usual flags on Maven 3.9.16, which Apache now lists as previous stable, the install succeeded and the first compile of a project that depends on it stopped with these lines, trimmed here.

[ERROR] Failed to read artifact descriptor for com.docmosis:docmosis-java:jar:4.9.1
[ERROR]   Caused by: The following artifacts could not be resolved: com.docmosis:docmosis:pom:4.9.1 (absent)

Several poms are packed inside the jar, and Maven registered one whose parent, com.docmosis:docmosis, does not exist on Central. The workaround is one more flag, which tells Maven to generate a minimal pom without the parent reference.

mvn install:install-file -Dfile=java-4.9.1.jar -DgroupId=com.docmosis \
    -DartifactId=docmosis-java -Dversion=4.9.1 -Dpackaging=jar -DgeneratePom=true

With -DgeneratePom=true the same project compiled. Maven 3.10.0, out since 27 September 2026 and Apache's current version, wrote that minimal pom without the flag, and the project compiled there too. Each Docmosis upgrade repeats the install, as does each machine that does not pull from a shared company repository, and the coordinates are a local choice because the vendor publishes none.

Starting the Core Without a Valid Key

The Configuration class is the start-up route the Developer Reference recommends, and it checks the key before it looks for LibreOffice. The manual's own sample chains setOpenOfficeLocation, which the 4.9.1 jar does not contain, so the code below calls setOfficeLocation instead.

import com.docmosis.SystemManager;
import com.docmosis.util.Configuration;

public class ConfiguredStart {
    public static void main(String[] args) throws Exception {
        // The Configuration route keeps the settings out of global system properties.
        Configuration config = Configuration.standard()
                .setKeyAndSite("YOUR-LICENSE-KEY", "YOUR-SITE-NAME")
                .setOfficeLocation("C:/Program Files/LibreOffice");

        // Start-up validates the key before it looks for LibreOffice.
        try {
            SystemManager.initialise(config);
            System.out.println("converters online");
        } catch (Exception e) {
            System.out.println(e.getClass().getSimpleName() + ": " + e.getMessage());
        } finally {
            SystemManager.release();
        }
    }
}

The run printed InvalidLicenseException: Unable to process the license:com.docmosis.util.InvalidLicenseException:No valid license available. and no converter came online. Data preparation, on the other hand, runs without a key, which makes the gap easy to miss in unit tests.

import com.docmosis.document.DocumentProcessor;
import com.docmosis.template.population.DataProvider;
import com.docmosis.template.population.DataProviderBuilder;

import java.io.File;

public class OrderJsonThenRender {
    public static void main(String[] args) throws Exception {
        String json = "{\"orderId\":\"PO-7731\",\"items\":[{\"sku\":\"A-100\",\"qty\":4},{\"sku\":\"B-220\",\"qty\":12}]}";

        // The JSON maps onto template data with no key and no converter involved.
        DataProviderBuilder dpb = new DataProviderBuilder();
        dpb.addJSONString(json);
        DataProvider data = dpb.getDataProvider();
        System.out.println(data.getString("orderId") + " items: " + data.getDataProviderCount("items"));

        // The PDF step is where the started core and its LibreOffice converter come in.
        try {
            DocumentProcessor.renderDoc(new File("purchase-order.docx"), new File("purchase-order.pdf"), data);
        } catch (IllegalStateException e) {
            System.out.println("render: " + e.getMessage());
        }
    }
}

Here the output read PO-7731 items: 2, followed by an IllegalStateException saying the store is unavailable until the factory is initialised, and no purchase-order.pdf appeared. A test suite can pass on the data side, yet with no key this render path produced no document. The vendor offers a 30-day trial key for evaluation, limited to one converter.

Tornado CVEs and the LibreOffice Patch Cycle

NVD returned four CVEs for a Docmosis keyword search on 4 November 2026, every one of them filed against the Tornado server product and none against Docmosis-Java.

• CVE-2023-25264, CVSS 3.1 score 7.5 (NIST): Crafted relative path segments bypass authentication in Tornado before 2.9.5.
• CVE-2023-25265, CVSS 3.1 score 7.5 (NIST): A directory traversal in Tornado 2.9.4 and earlier.
• CVE-2023-25266, CVSS 3.1 score 8.8 (NIST): A signed-in user can redirect Tornado's office path to a network share and have Tornado run the soffice binary found there, in releases before 2.9.5.
• CVE-2024-42733, CVSS 3.1 score 9.8 (CISA-ADP): Code execution through a crafted script sent to the UNC path input in Tornado 2.9.7 and earlier, its only score, with no fixed version listed by NVD.

NVD gives 2.9.5 as the fixed release for the first three. The GitHub report NVD cites for the fourth says those fixes could be bypassed in 2.9.7, and a Docmosis commit dated 4 November 2024 closed that report by moving its Docker image to Tornado 2.10.0, stating that all items have been addressed.

The Tornado 2.11.4 release notes (August 2026) add a flaw with no CVE, one of several security fixes those notes list without a number. The storeTo=file: option of the render API could write generated content to unintended locations, and 2.11.4 disables it until a path whitelist is configured.

LibreOffice keeps its own advisory list, so a converter host has a second set of records to read, for Docmosis-Java and Tornado alike. On 5 October 2026 it published six, CVE-2026-63266 through CVE-2026-63270 plus CVE-2026-63277, whose records name the 26.2 series below 26.2.5, with the fixes shipped in versions 26.2.5 and 26.8.0. Its page now adds CVE-2026-76181, fixed in 26.2.6 and 26.8.1. Whether any of them applies depends on the version a host runs, and the Docmosis 4.9.1 download page names LibreOffice 7. The Docmosis manual asks for automatic updates to stay off.

LibreOffice on Every Converter Host

Every converter runs on LibreOffice, so each machine hosting one carries that office suite. Version 6 is the minimum in the Developer Reference, while the 4.9.1 download page names version 7. The JVM and LibreOffice have to share a bitness, LibreOffice 7 or newer needs Java 8 or newer, servers should match each other version for version, and Linux machines need a set of X libraries. When converters do not launch, the Developer Reference points first at the LibreOffice setup. Release 4.9.0 from October 2025 lists turning off automatic updates for LibreOffice 24 among its stability fixes.

Where the converters live is a choice between two sets of costs. Run embedded, they share a JVM with the Docmosis core, stay on that one machine, and go down and come up only together with the core. Run remotely, each machine needs its own office install plus a service that starts the converter at boot. Initialisation is slow enough that the manual recommends doing it once per application lifetime.

HTML Snippets, Floating Images and PDF/A Levels

Docmosis templates are Word or Writer documents, so HTML arrives through a <<html:name>> field. The Template Guide cautions that complex HTML can come out differently in the document than in a browser, and it points users to inline styles and simple snippets. Pictures in Word templates must be inline too, since Docmosis locates each one through a bookmark that Word strips from floating pictures.

Archive output follows the installed LibreOffice. setPdfVersion on ConversionInstruction offers PDF/A-1b, PDF/A-2b from LibreOffice 6 and PDF/A-3b from LibreOffice 7, the 4.9.1 PdfVersion enum has no a-level entry, and setPdfArchiveMode has been deprecated since 4.8.0. The PDF/A guide for Java explains what the archive format is for. By default a broken field is printed into the output in red, because the populator's fatal-error property starts as false, and the vendor tells production systems to switch it on.

A Route Without the Converter Pool

IronPDF for Java, sold commercially by Iron Software, replaces the converter with its own engine. Templates are HTML and CSS, rendered by Chromium with page JavaScript on by default. Rendering happens in IronPdfEngine, which is downloaded for the platform the first time the library runs or bundled through a platform-specific Maven artifact, so no LibreOffice goes on the host and engine updates arrive with IronPDF upgrades. com.ironsoftware:ironpdf itself is an ordinary Maven Central coordinate, published eleven times in 2026 up to version 2026.11.3, and the engine can also run on a separate server kept at the matching version, as the IronPdfEngine guide shows.

With IronPDF, the purchase order becomes an HTML string passed to PdfDocument.renderHtmlAsPdf. We ran one on 2026.11.3 and veraPDF passed the converted file as PDF/A-3b, and a version of the page with a title and language set also passed through convertToPdfA as PDF/A-1a, 2a and 3a, the a-levels that Docmosis enum lacks. IronPDF offers a free trial for running it against your own templates, and the HTML file example covers templates kept on disk.

Recap of the Docmosis Checks

Docmosis-Java 4.9.1 needs a manual Maven install, with -DgeneratePom=true on Maven 3.9.16, a valid key at start-up and LibreOffice installed on every converter host, and its PDF/A levels stop at 3b, while Tornado's record holds four CVEs plus fixes with no number, such as the storeTo=file: flaw. IronPDF for Java takes HTML templates in place of Word ones, resolves from Central and renders in Chromium, and its guide to PDFs from templates shows the HTML template setup.

Docmosis is a trademark of Docmosis Pty Ltd, LibreOffice belongs to its owner, we have no affiliation with either, and the details here come from the vendor's public manuals and release notes, NVD, the LibreOffice advisories page, GitHub and Maven Central.

Drafted with AI. Docmosis code run against Docmosis-Java 4.9.1 and Maven 3.9.16 and 3.10.0, and claims checked by the Iron Software DevRel team on 4 November 2026, with com.ironsoftware:ironpdf 2026.11.3 as the IronPDF reference.