http://issues.apache.org/jira/secure/attachment/12348234/WindowsPath.support throws SDOFileNotFoundException for non-existent path.
As for xmlCanonicPath, it always allocates new memory and expects xmlFree where try/finally simulation may also complicate code. Trading off for performance, mine only allocates new memory when necessary and implicitly frees on destruction. I can't make up my mind. Anyone preferring xmlCanonicPath can go ahead modify the patch even source (after applying) directly. On 1/3/07, Caroline Maynard <[EMAIL PROTECTED]> wrote:
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
-- Yang ZHONG
