[ http://issues.apache.org/jira/browse/AXIS-1887?page=comments#action_61362 ] Clive Brettingham-Moore commented on AXIS-1887: -----------------------------------------------
I don't have a patch (I just took the path of least resistance and beefed up my classpath). My feeling is that this issue is symptomatic of an architectural limit in tcpmon - the underlying model used for the data is not really sophisticated enough to fully support encoding - making it so would require large changes to the application (case in point - what happens for resend in the current version). Simplest would be to use an encoding variable, pick up content type in the header handling code (line ~1100) to set this. XML decl is more complex - could test the first two non whitespace body chars for <?, but unless a pushback input stream is used this will cause problems with the XML formatter is there isn't a decl. If I had the time to do it the larger rewrite would be relatively simple (and solve some other problems): Extracting content-type or the xml declaration will require more complicated parsing than is currently done. Replace the default document in the text area with a custom document backed by the actual byte data. The backing data can be updated by the socket's thread with GUI update handled in a GUI thread (currently slow GUI operations like appending to really long lines slow transmission). This also has the advantage that reparsing/decoding of the data is possible, if the first guess didn't work. Would probably have two modes for the model: raw and http/xml. Vanilla resends could then be served direct from the binary data, and edits could attempt some encoding smarts. This (above) may be too much in a siple tool like tcpmon. It's a fine line between flexibility and bloat. > tcpmon unable to display messages: faulty lookup of encoding > ------------------------------------------------------------ > > Key: AXIS-1887 > URL: http://issues.apache.org/jira/browse/AXIS-1887 > Project: Axis > Type: Bug > Versions: 1.2RC3 > Environment: ALL (particularly tcpmon running independent of axis > server/client) > Reporter: Clive Brettingham-Moore > Priority: Minor > > The handling of encoding introduced to fix AXIS-1815, ie using > XMLUtils.getEncoding() is fragile and greatly increases the classpath needed > to run tcpmon (use of XMLUtils forces loading of saaj, jaxrpc, > commons-logging and commons-discovery; previously only axis.jar was > required), and the value returned appears to have no significance to the > message being displayed anyway (AFAICS if tcpmon is in a separate vm it will > just default since there will be no engine and no messages) > Encoding would be better picked up from the content-type header and/or the > xml declaration of the message, or let the user manually specify a fallback > encoding for display. > If you run tcpmon with only axis.jar and don't look at the console (assuming > you even run it from one) it only displays the headers for the request and > nothing else (due to class not found error), which could be very confusing > for people trying to debug an app. This bug will catch many who run tcpmon > from the command line or scripts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
