The resource provided to DOMResourceStage is checked during stage initialisation for #exists(), and stage initialisation fails if that check does not succeed.
However, if #getInputStream() subsequently fails on the resource, the "finally" clause of the "try" in doExecute will still try to close the input stream and provoke a NullPointerException instead of the intended behaviour.
Reworking doExecute in terms of the try-with-resources construct would be the neatest way to fix this. Writing a unit test is harder, as almost all resources which exist are readable. The case in question was noticed when an HTTP resource checked as existing at the time of stage initialisation but then failed (timeout?) when the stage was later executed, but that's obviously hard to reproduce in a test.