I posted the traceback to show that it's XSDHelperImpl::defineFile(). The file spec is being passed in from the user, and I do think that Windows users normally expect to specify file specs in this way, and I see no reason to regress this behaviour in your fix. Especially not with an AccessViolation :-)
On 03/01/07, Yang ZHONG <[EMAIL PROTECTED]> wrote:
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
-- Caroline
