The good news is that the fix does work for me. Though I would suggest thinking about using xmlCanonicPath() to keep the Tuscany code simpler and the URI function in libxml where it belongs. xmlCanonicPath() will silently handle platform-specific paths, too.
The bad news is that the tests still fail. This time the problem is a test which deliberately calls defineFile() with a non-existent file spec. I get the same traceback for the access violation: MSVCRTD! 00239060() commonj::sdo::SAX2Parser::parse_twice(const char * 0x00000000) line 436 + 17 bytes commonj::sdo::SDOSchemaSAX2Parser::parse(const char * 0x00000000) line 1318 + 17 bytes commonj::sdo::ParserErrorSetter::parseIfNot(const void * 0x02d92f88, unsigned char 0x00, const void * 0x00000000) line 556 + 17 bytes commonj::sdo::XSDHelperImpl::defineFile(const char * 0x02d92f88, unsigned char 0x00) line 111 + 21 bytes The cause is the same as the first example - xmlBuildURI() is returning null when passed an invalid location, and there is no guard for this condition. Before your fix was applied, Tuscany would throw an SDOFileNotFoundException. On 03/01/07, Yang ZHONG <[EMAIL PROTECTED]> wrote:
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.
-- Caroline
