Spring is still falling through to remote access of XML files

They won’t fix it for compatibility reasons but after a quick test, it’s landing in the same try/catch frame if I raise a runtime exception, so I just converted to use a BeanDefinitionStoreException and cleaned up our custom class so it eliminates the duplication I had to do before.

They neglected to allow the overridden method to raise an exception so there’s no way to short-circuit what it’s doing. If I raise a runtime error I don’t know what that will do so I don’t prefer to go down that road and have to re-test. If they ever fix it, we’ll revisit.

We should be using a new enough Spring version now that they may have added a protected method I can hook to avoid some of the duplication I did.

Fix for the immediate issue in Spring and a canary test added to the new library. I will backport this to spring-extensions.

The problem isn’t that they don’t use an EntityResolver but that their ResourceEntityResolver class defaults to falling into http/s resolution.

Filed a Spring bug in case they decide to care, https://github.com/spring-projects/spring-framework/issues/29662

The problem is compounded by a gem of a comment inside JAXP in Java that basically says “if the ER returns null, should we really do it ourselves or return null?” Of course you know what they did. The only way around that is to throw an exception inside the EntityResolver.

Thus, the fix I found was to clone yet another Spring class and cut out the bad bits and add a log and throw.

I will add a canary test for this as well.