I've tried http://issues.apache.org/jira/secure/attachment/12348221/XSDHelperImpl.990 and I think it supports Windows path on Windows (only).
Let me know if your case still fails. On 1/3/07, Caroline Maynard <[EMAIL PROTECTED]> wrote:
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
-- Yang ZHONG
