Skip to content
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

Open
ahayes opened this issue Mar 31, 2020 · 5 comments
Open

PDF attachments get stuck in processing state #900

ahayes opened this issue Mar 31, 2020 · 5 comments
Assignees
Labels
Bug Design or implementation flaw that causes grief.
Milestone

Comments

@ahayes
Copy link
Member

ahayes commented Mar 31, 2020

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 out assistive_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.

@ahayes ahayes added the Bug Design or implementation flaw that causes grief. label Mar 31, 2020
@ahayes ahayes added this to the 2.2.9 milestone Mar 31, 2020
@ahayes
Copy link
Member Author

ahayes commented Mar 31, 2020

@sruest
Copy link
Contributor

sruest commented Apr 1, 2020

Our documentation even describes commenting out the assistive_technologies property in accessibility.properties. See "2. Build Nunaliit" in https://github.com/GCRC/nunaliit/wiki/Nunaliit-Documentation-for-Developers#building

@ahayes ahayes closed this as completed in 21aa557 Apr 1, 2020
ahayes added a commit that referenced this issue Apr 1, 2020
fix #900: Set the accessibility system property to false at startup, …
@ahayes
Copy link
Member Author

ahayes commented Sep 17, 2020

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.

@ahayes ahayes reopened this Sep 17, 2020
@ahayes ahayes assigned ahayes and unassigned sruest Sep 17, 2020
@ahayes ahayes assigned eilanlaken and unassigned ahayes Oct 26, 2020
@ahayes
Copy link
Member Author

ahayes commented Oct 26, 2020

Fixing this in the test cases should also close issue #777

@ahayes ahayes assigned billingb and unassigned eilanlaken Sep 9, 2021
@ahayes
Copy link
Member Author

ahayes commented Sep 22, 2021

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Design or implementation flaw that causes grief.
Projects
None yet
Development

No branches or pull requests

4 participants