Closed mauromol closed 3 years ago
Not sure about this one, I will need to investigate
In #327 I wrote some more details after my investigations (I used a proxy to intercept remote HTTP calls). I'm quite convinced that, when running locally (i.e.: unit tests) schemas residing on the local file system can be found and are used by default, while this mechanism breaks when schemas are put in a JAR. With this change, a LSResourceResolver
ensures that all the needed schemas are loaded from the classpath in any case. All unit tests still pass and I can state for sure that remote calls are not done any more in my main application where I use java-saml as a JAR.
Schemas in main/resources were not correctly used on schema loading when java-saml was used as a JAR in a consuming application. It seems like the local XSD files for imported schemas were used only when running unit tests, while remote HTTP lookups from the W3C website were made when using java-saml as a JAR. Now a LSResoureResolver is set on the schema factory so that any known XSD or DTD is loaded from the classpath, even when inside a JAR. Any other (unknown) schema is resolved in the standard way (and may involve a remote call). Also, in the unlikely event that retrieving the local copy of the XSD/DTD is impossible, a fallback mechanism ensures the standard resolution is performed.
Please note that the online version of xenc-schema.xsd contains a reference to the XML Schema DTD. Now that we can resolve resources locally, I decided to keep the DTD and include it in /schemas package (along with the datatypes DTD). This should provide an even more comprehensive schema validation.
Closes #327.