CODEWITHSUNDEEP
javamavendockermaven-pluginpdfbox
radder5
radder5

Reputation: 236

Generation of pdf PDFBox headless docker container fails

I am using pdfbox to create pdfs in Java. This works fine when running from my Mac as a normal Java application. However, the use case is to run this from server side to generate the pdf from a web browser.

I have deployed the application into a docker container and now fails to work (various errors when loading fonts - arrayindexoutofbounds, eofexception etc.). This appears to be due to the way pdfbox runs in java.awt.headless mode as when I output the mode java is running in on Mac it returns false for headless mode, whereas it returns true running on server.

I have set the java.awt.headless=false setting explicitly within my code to and now come up with a number of other errors. Missing libraries relating to X server etc. I have installed these but now have the error: 

java.awt.AWTError: Can't connect to X11 window server using ':0.0' as the value of the DISPLAY variable.

There is a bunch of suggestions around SO and the like, e.g. setting DISPLAY=:0.0 etc. but none of these work. This is obviously somewhat complicated by running in docker container, but can anyone suggest something here?

I am guessing using virtual xserver is the answer but I am stumped on how to set this up, and then set the appropriate xsessionAuthoriy/ DISPLAY/ etc.

Upvotes: 1

Views: 1138

Answers (1)

radder5
radder5

Reputation: 236

This wasn't anything to do with running in headless mode as it turns out. The initial errors that were being thrown were the actual error (i.e. the font files were corrupt) and I should have stuck with the investigation of these.

The issue was with the way maven was packaging my application with a mixture of binary and text resources. Adding 

<resources>
    <resource>
        <directory>target/classes</directory>
    </resource>
    <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
    </resource>
</resources>
<nonFilteredFileExtensions>
    <nonFilteredFileExtension>ttf</nonFilteredFileExtension>
</nonFilteredFileExtensions>

to my maven pom stopped the fonts being mangled.

Thanks for the pointers though. For the record, I did get Xvfb working and the display env variable set, which when working, got me back to the original error about fonts being corrupt. To get Xvfb running to get to this, I had to override the entrypoint on the docker run command to get a bash container, then started my vert.x process from within the container.

Upvotes: 1

Related Questions