Are you using "C:\path\to\the.xsd" as schemaLocation for include/import?
According to XSD spec, it should have been "a URI as defined by [RFC 2396],
as amended by [RFC 2732]".
Both RFC 2396 and RFC 2732 have specified "\" unwise.

Or are you using "C:\path\to\the.xsd" for XSDHelper#defineFile?
Neither SDO spec 2.1 C++ nor the Java counterpart seems specifying the
input.
I think it's reasonable to support that for XSDHelper#defineFile on Windows
only.
What's everyone's opinion?

On 1/3/07, Caroline Maynard <[EMAIL PROTECTED]> wrote:

This isn't looking good for me. Tests which previously worked are now
failing with :

MSVCRTD! 00239060()
commonj::sdo::SAX2Parser::parse_twice(const char * 0x00000000) line 436 +
17
bytes
commonj::sdo::SDOSchemaSAX2Parser::parse(const char * 0x00000000) line
1316
+ 17 bytes
commonj::sdo::ParserErrorSetter::parseIfNot(const void * 0x01a8cad0,
unsigned char 0x00, const void * 0x00000000) line 554 + 17 bytes
commonj::sdo::XSDHelperImpl::defineFile(const char * 0x01a8cad0, unsigned
char 0x00) line 83 + 21 bytes

This is probably because the schema is specified as a Windows-style
filespec: C:\path\to\the.xsd. It would probably work with your changes if
the location was a valid URI, so that xmlBuildURI() returns a valid URI,
but
I think the code should work in either case.

On 03/01/07, Geoff Winn (JIRA) <[email protected]> wrote:
>
>
>      [
>
https://issues.apache.org/jira/browse/TUSCANY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
>
> Geoff Winn resolved TUSCANY-990.
> --------------------------------
>
>        Resolution: Fixed
>     Fix Version/s: Cpp-current
>
> Patch applied.
>
> The standard tests now produce just 5 I/O warnings about failing to load
> an external entity.
>
> > Avoid duplicated/infinite loading
> > ---------------------------------
> >
> >                 Key: TUSCANY-990
> >                 URL: https://issues.apache.org/jira/browse/TUSCANY-990
> >             Project: Tuscany
> >          Issue Type: Improvement
> >          Components: C++ SDO
> >    Affects Versions: Cpp-current
> >            Reporter: Yang ZHONG
> >             Fix For: Cpp-current
> >
> >         Attachments: AvoidInfiniteLoading.990,
AvoidInfiniteLoading.990
> >
> >
> > While working on http://issues.apache.org/jira/browse/TUSCANY-907
> > I've observed duplicated XSD loading. It could be infinite loading. I
> might have a way to avoid that.
> > http://pecl.php.net/bugs/bug.php?id=9243
> > has the Test Case:
> >     1. http://ping.chip.org/phr/xml/insurance.xsd imports
> http://ping.chip.org/phr/xml/types.xsd
> >     2. http://ping.chip.org/phr/xml/insurance.xsd imports
> http://ping.chip.org/phr/xml/contact.xsd which also imports
> http://ping.chip.org/phr/xml/types.xsd
> > I've observed http://ping.chip.org/phr/xml/types.xsd is loaded/parsed
> multiple times during loading http://ping.chip.org/phr/xml/insurance.xsd
> > That impacts performance, especially types.xsd is remote.
> > More deadly, that may cause infinite loading or stack overflow.
> > Imagine A imports B which imports A, or X imports Y which imports Z
> which imports X.
> > We can have a LoadingContext/ResourceSet to cache loaded/parsed
> resources, and reuse parsing results if a location/URI has been
> loaded/parsed already.
> > 3-1. The LoadingContext/ResourceSet can be a Thread Local
> > 3-2. The LoadingContext/ResourceSet can be explicitly passed into each
> parser
> > 3-3. Currently ParserErrorSetter is explicitly passed into each
parser,
> which can host the LoadingContext/ResourceSet
> > Above has been discussed on thread
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
> > and Caroline has also requested this improvement (
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11839.html)
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> https://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
http://www.atlassian.com/software/jira
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Caroline




--

Yang ZHONG

Reply via email to