DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7077>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7077 ICUMsgLoader doesn't load messages! Summary: ICUMsgLoader doesn't load messages! Product: Xerces-C++ Version: 1.6.0 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Symptom: Whenever parsing or schema errors occur (e.g. with SAX2Print or DOMPrint) the produced message printed indicates the file, line and column numbers but the message portion is empty. I've verified my schema with SQC (No errors) but XML4C is complaining about the schema. I'd like to know what its complaining about so I can debug the problem, but since it doesn't print the messages, I can't. For example, here's the output from SAX2Print: <?xml version="1.0" encoding="LATIN1"?> Error at file /proj/work/test.xml, line 3, char 100 Message: Error at file /proj/work/test.xml, line 3, char 100 Message: ... Note that line 3 is actually where the schema for test.xml is declared and these are schema errors being reported by SAX2Print. That problem has already been documented in another bug and scheduled for fixing. The problem at hand occurs for both content and schema errors as well. WorkAround: Don't use the ICUMsgLoader (specified when you runConfigure). Instead, use the "inmem" message loader. Analysis: In GDB, I've walked through the details of loading a message with the ICUMsgLoader. What I'm suspicious about is the mapID function at line 107 of src/util/MsgLoaders/ICUMsgLoader.cpp. The function always returns a "test" key containing the characters "ef". It >should< map the XMLMsgId to a message key. Here's the code: static const XMLCh* mapId( const XMLMsgLoader::XMLMsgId msgToLoad , const XMLCh* bundleType) { static const XMLCh test[] = { 0x65, 0x66, 0 }; return test; } This looks highly suspicious to me as it doesn't really do any "mapping". This result (the Unicode string "ef"), is returned into the ICUMsgLoader::loadMsg method and then passed to XMLString::transcode and that result is then passed into ResourceBundle::getStringEx (line 161 of ICUMsgLoader.cpp in the loadMsg method). Here's the code (with my comments sprinkled in): #line 150 const XMLCh* const keyStr = mapId(msgToLoad, fBundleType); if (!keyStr) return false; // NOTE: The keyStr returned is always "ef" UErrorCode err; UnicodeString msgString = fBundle->getStringEx( XMLString::transcode(keyStr), err ); // NOTE1: This ALWAYS returns an empty string. // NOTE2: The "err" is not checked here. It should be. const unsigned int len = msgString.length(); // NOTE: len always 0 const unsigned int lesserLen = (len < maxChars) ? len : maxChars; // NOTE: lesserLen always 0 msgString.extract ( 0, lesserLen, toFill ); toFill[lesserLen] = 0; return true; In this snippet, lesserLen is always 0 and so the length of the returned string is always zero, even if msgString.extract did manage to copy some characters that looked like an error message into the toFill buffer. I suspect one of two things. Either the "fake" key (i.e. it might be right, it just looks suspicious to me) returned by mapID isn't valid and so getStringEx returns an empty string. Or, there is some error occurring in ResourceBundle::getStringEx and since its UErrorCode is not being checked, there is no "Error getting error" panic generated. The returned message, regardless of the XMLMsgId provided is always the empty string, and the proof is in the pudding when you look at the output of the program. I'm not sure that my analysis is correct. Does this seem right to you? It looks to me like the ICUMsgLoader class is partially implemented, or that the last change to get it to compile with GCC 3.0.3 botched something up. Has anyone else run into this problem? Environment Details: O/S: Red Hat Linux 7.1 (Kernel 2.4.2.2) Compiler: GCC 3.0.3 ICU: 2.0.1 XERCESC: 1.6.0 and 1.7.0 LOCALE: en_US --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
