I fixed the issue under r783211 yesterday. It is consistent with the
proposal you have.
I added a customized ResourceResolver to resolve schemaLocation. For those
locations from SCA spec XSDs that point to a file on the web, we now use a
local copy based on the target namespace.
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <[email protected]>
Sent: Wednesday, June 10, 2009 10:45 AM
To: <[email protected]>
Subject: Re: SCA Schema validation issues - a bigger question
Folks,
I'd like to raise the wider question here about the Tuscany SCA runtime
going out over the internet to fetch XSD files.
Why oh why are we doing this?
It guarantees failures whenever Tuscany is run somewhere that is offline.
It implies poor performance while the XSDs are downloaded.
It implies exposure to failures due to unavailabilty of the remote
location from which the XSD is fetched. This last is completely
unacceptable in any serious server runtime.
In my opinion:
a) any XSDs Tuscany depends on should be packed with the Tuscany
distribution and only ever searched for locally
b) the XSDs we depend on are not going to change so having them locally is
not a problem
c) if there are any XSDs we can't have locally for any reason then we
should stop depending on them at all
The irony is that the failure that affected us last night & this morning
is in relation to a file that we DO HAVE LOCALLY - just that we not
searching for it due to bad location parameters. I fixed the problem for
myself by patching the <import/> statements to point to the local file.
So, let's fix Tuscany by getting local copies of all relevant XSDs.
Anyone disagree?
Yours, Mike.
Raymond Feng wrote:
Hi,
The SCA XSDs from OASIS has "import" to XSD files on the web. This makes
our schema validation unreliable as it tries to connect to the internet.
I'm seeing failure in assembly-xml:
org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name
'wsdli:wsdlL
ocation' to a(n) 'attribute declaration' component.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAX
ParseException(ErrorHandlerWrapper.java:195)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(Err
orHandlerWrapper.java:131)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(
XMLErrorReporter.java:384)
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.repo
rtSchemaErr(XSDHandler.java:2537)
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.repo
rtSchemaError(XSDHandler.java:2528)
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.getG
lobalDecl(XSDHandler.java:1396)
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDAttributeTra
verser.traverseLocal(XSDAttributeTraverser.java:83)
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDAbstractTrav
After hours of debug, I found the underlying error is caused by the
following exception. It seems that the connection from URL.openStream()
is rejected even though it can be accessed from the browser (not sure if
it is an anti-spamming thing).
java.io.IOException: Server returned HTTP response code: 403 for URL:
http://www.w3.org/2001/datatypes.dtd
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1305)
at java.net.URL.openStream(URL.java:1009)
I found a workaround by setting a feature on the SchemaFactory.
// Set the feature to avoid DTD processing
schemaFactory.setFeature("http://xml.org/sax/features/external-parameter-entities";,
false);
I'm also trying to add a Resolver so that XSDs on the web can be
redirected to a local copy.
Thanks,
Raymond
