New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PDF attachments get stuck in processing state #900
Comments
Our documentation even describes commenting out the |
fix #900: Set the accessibility system property to false at startup, …
Reopening this to help remember that the testcase that runs during the build needs the same fix to avoid having to modify the system config. |
Fixing this in the test cases should also close issue #777 |
@billingb , when you get to your testing, could you doublecheck that we no longer need imagemagik PDF support and that all processing is now accomplished by PDFBox? If so, we can pull out a little section from the prerequisite install guides that enables imagemagik PDF support. |
It looks like PDFBox tries to make use of AWT accessibility features if they are enabled. With Ubuntu's headless JRE/JDK packaging, AWT is there in some capacity but its accessibility features are not. This causes it to fail on headless servers but succeed on developer workstations that are not running the headless version of the JDK. We don't need these features as we don't have a GUI of any sort on the Java side.
As described in one of the answers to this AskUbuntu question , the accessibility features can be disabled in
/etc/java-8-openjdk/accessibility.properties
by commenting outassistive_technologies=org.GNOME.Accessibility.AtkWrapper
This is helpful as a workaround but for us to avoid another config file change by people installing Nunaliit (and possibly affecting other java environments on a server), we should disable it when we run by passing
-Djavax.accessibility.assistive_technologies=" "
when starting the JVM to run our servlet (in Jetty config?). This is also documented in another AskUbuntu answer to the same question.We should also evaluate our build test cases to see if PDF processing is something we can test for to avoid a regression in the future. I believe our TravisCI builds are using a headless JDK.
The text was updated successfully, but these errors were encountered: