You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Aki Yoshida <el...@gmail.com> on 2013/12/11 12:06:23 UTC
issue with schema loading in spring
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
Re: issue with schema loading in spring
Posted by Aki Yoshida <el...@gmail.com>.
Hi Dan,
Okay. My question was about those oasis schemas included in
rt-ws-policy and I think these imports can be reverted to absolute as
they are included in the namespace handler's mapping.
Regarding the import of xml.xsd, I think we probably don't need it for
the policy schema itself as it is not being used there (originally,
explicitly imported as in the original version, but not in the local
copy now). So, you will be only needing BP 1.2, if you are using
xml.xsd stuff directly from your blueprint.xml or indirectly over some
schema that is explicitly importing it.
regards, aki
2013/12/16 Daniel Kulp <dk...@apache.org>:
>
> On Dec 16, 2013, at 8:13 AM, Aki Yoshida <el...@gmail.com> 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 <el...@gmail.com>:
>>> 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 <dk...@apache.org>:
>>>>
>>>> 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 <el...@gmail.com> 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
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: issue with schema loading in spring
Posted by Daniel Kulp <dk...@apache.org>.
On Dec 16, 2013, at 8:13 AM, Aki Yoshida <el...@gmail.com> 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 <el...@gmail.com>:
>> 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 <dk...@apache.org>:
>>>
>>> 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 <el...@gmail.com> 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
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: issue with schema loading in spring
Posted by Aki Yoshida <el...@gmail.com>.
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.
regards, aki
2013/12/16 Aki Yoshida <el...@gmail.com>:
> 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 <dk...@apache.org>:
>>
>> 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 <el...@gmail.com> 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
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
Re: issue with schema loading in spring
Posted by Aki Yoshida <el...@gmail.com>.
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 <dk...@apache.org>:
>
> 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 <el...@gmail.com> 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: issue with schema loading in spring
Posted by Daniel Kulp <dk...@apache.org>.
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 <el...@gmail.com> 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com