cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@gmail.com>
Subject issue with schema loading in spring
Date Wed, 11 Dec 2013 11:06:23 GMT
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

Mime
View raw message