On Dec 16, 2013, at 8:13 AM, Aki Yoshida <[email protected]> wrote: > Hi Dan, > just saw CXF-5181 which switched to use the relative paths for imports. > [CXF-5181] Use relative paths in imports so blueprint validation can > work without long startup delays and internet access. > > But in this patch, those schemas were also added to the namespace > handler's schema mapping. So I suppose those schemas can get loaded > locally even when the locations are kept as absolute as long as if you > are not using an older Aries BP core like 0.3.2. I'll check on this. >
You likely need BP 1.2. A couple of the schemas import the xml schema and it didn’t seem right to put the import for that anyplace in CXF. You’d likely get into a situation where multiple bundles would need to have it registered. Thus, that schema was added to BP: https://issues.apache.org/jira/browse/ARIES-1118 Dan > regards, aki > > > > 2013/12/16 Aki Yoshida <[email protected]>: >> Hi Dan, >> thanks for your input. >> >> In that case, I will go ahead and update the local schemas to use the >> absolute URLs for the imports. >> As most imports are already using the absolute URLs and they are >> working also for offline, if some issue occurs after this change, that >> likely just means we forgot to include that particular URL in the BP's >> ns-handler's schema map. Then, we can fix it there. >> >> regards, aki >> >> 2013/12/13 Daniel Kulp <[email protected]>: >>> >>> Aki, >>> >>> Most of the flipping to relative locations was to work around namespace >>> handler issues in Blueprint. I think those issues are now fixed in the >>> latest blueprint, but I’m not sure if the latest Karaf releases have been >>> updated yet. If not, we could always start pushing them a bit harder. :-) >>> >>> If we can verify the various situations in blueprint won’t go off to the >>> internet to grab schemas, we could revert them back. >>> >>> Dan >>> >>> >>> On Dec 11, 2013, at 6:06 AM, Aki Yoshida <[email protected]> wrote: >>> >>>> 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 >>> >>> -- >>> Daniel Kulp >>> [email protected] - http://dankulp.com/blog >>> Talend Community Coder - http://coders.talend.com >>> -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
