I have a couple of comments. 1. In the patch XSDHelperImpl.990 you _must_ add comments to explain what the code is doing and why.
2. Regarding xmlCanonicPath, performance is not an issue. This section of code won't be called often enough to matter, whereas reliability and clarity (for people reading it in future) are essential. So whether we use xmlCanonicPath or not should be based on which one is easier to understand in future. Caroline, I've looked on the libxml2 website and the description of xmlCanonicPath that I found is pretty thin. Do you have a pointer to a decent explanation of what it does? Regards, Geoff. On 04/01/07, Yang ZHONG <[EMAIL PROTECTED]> wrote:
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
