axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clive Brettingham-Moore (JIRA)" <axis-...@ws.apache.org>
Subject [jira] Commented: (AXIS-1887) tcpmon unable to display messages: faulty lookup of encoding
Date Tue, 22 Mar 2005 06:47:25 GMT
     [ 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


Mime
View raw message