I noticed a problem of loading a certain xsd schema in spring and I identified the cause. But as I remember that we have had a few rounds of changes in the past and I would like to ask you if the suggested fix makes sense.
The problem occurs when I try to look up the schema for namespace "http://www.w3.org/ns/ws-policy"; and I have its schemaloc in my beans.xml correctly set to "http://www.w3.org/2007/02/ws-policy.xsd"; And as this location is given in the rt-ws-policy's catalog file which maps this location to its local resource file "schemas/ws-policy-200702.xsd". So far, it's fine. and this local schema resource has the following import: <xs:import namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"; schemaLocation="oasis-200401-wss-wssecurity-secext-1.0.xsd" /> and here it hits the problem because the schema processor thinks this schema to be imported is located at http://www.w3.org/2007/02/oasis-200401-wss-wssecurity-secext-1.0.xsd, as the parent schema "ws-policy.xsd" was supposed to be located at "http://www.w3.org/2007/02/"; and tries to load it from there and results in Caused by: java.io.FileNotFoundException: http://www.w3.org/2007/02/oasis-200401-wss-wssecurity-utility-1.0.xsd at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1457) at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source) at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source) at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(Unknown Source) at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(Unknown Source) at org.apache.xerces.impl.xs.opti.SchemaDOMParser.parse(Unknown Source) ... 58 more The real schema is located at http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd and this location is also given in rt-ws-policy's catalog file and mapped to its local schemas/oasis-200401-wss-wssecurity-secext-1.0.xsd. One way to fix this issue is to change the way the schemaLocation is resolved after a catalog look up occurs that switches the location so that in the above case, schemaLocation="oasis-200401-wss-wssecurity-secext-1.0.xsd" will resolve directly to "schemas/oasis-200401-wss-wssecurity-secext-1.0.xsd" instead to its logical location "http://www.w3.org/2007/02/oasis-200401-wss-wssecurity-utility-1.0.xsd";. But I find this approach is somehow invasive. The better approach would be to always use the absolute location URLs in the schemaLocation attribute of "import"s. In contrast, for "include"s, we can keep the local URLs because the namespace nor the location path is not switched. I think the original schemas always had the absolute URLs for their imports. So, making this change means that we can put the unmodified schemas in the local resources folder and let the catalog and blueprint handler to do the resolution. Should we make this change or will there be some concern or alternative approach? thanks. regards, aki
