Enterprise Client Community

Hi,

If certain control characters are written in a textfield (e.g. the user copies a "corrupt" text from another application and paste it into the textfield), then a SAX xml-parser exception occurs. Example: Character 0x1A () . Or are there possibilites to avoid that ?

java.lang.RuntimeException: org.xml.sax.SAXParseException: Character reference "" is an invalid XML character.
at org.eclnt.client.elements.PageParserUpdate.applyXML(PageParserUpdate.java:182)
at org.eclnt.client.page.Page.processUpdateResponse(Page.java:920)
at org.eclnt.client.page.Page.access$2(Page.java:897)
at org.eclnt.client.page.Page$MyUpdateDataTransferListener.dataTransferEnded(Page.java:160)
at org.eclnt.client.comm.http.DataTransfer.transferXMLFinished(DataTransfer.java:786)
at org.eclnt.client.comm.http.DataTransfer.communicateToServerSynchronous(DataTransfer.java:209)
at org.eclnt.client.page.Page.transferDataRun(Page.java:791)
at org.eclnt.client.page.Page$DataTransferRunner.run(Page.java:120)
at org.eclnt.client.page.Page.callServerRun(Page.java:769)
at org.eclnt.client.page.Page$CallServerRunner.run(Page.java:80)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at org.eclnt.client.page.BlockingEventQueue.dispatchEvent(BlockingEventQueue.java:156)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Caused by: org.xml.sax.SAXParseException: Character reference "" is an invalid XML character.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:174)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:38

at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1411)
at com.sun.org.apache.xerces.internal.impl.XMLScanner.scanCharReferenceValue(XMLScanner.java:1295)
at com.sun.org.apache.xerces.internal.impl.XMLScanner.scanAttributeValue(XMLScanner.java:851)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanAttribute(XMLDocumentFragmentScannerImpl.java:1539)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1316)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2747)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:64

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
at org.eclnt.client.elements.PageParserUpdate.applyXML(PageParserUpdate.java:175)
... 18 more

Hi,

yes, we can reproduce - and just check how we can solve the problem. The characters is transferred as "" in the XML string, so we so far believed that this is enough to fit to XML...

We'll check... (short term)

Björn

....fyi: from the w3c spec...:

Note:

Document authors are encouraged to avoid "compatibility characters", as defined in Unicode [Unicode]. The characters defined in the following ranges are also discouraged. They are either control characters or permanently undefined Unicode characters:

[#x1-#x8], [#xB-#xC], [#xE-#x1F], [#x7F-#x84], [#x86-#x9F]
(and areas far above these ranges)

"encouraced to avoid" means "SAX parse exception"... ;-)

We will extend the XML writer to respect these areas... - and just wipe them out on their way to the client, to be sure that they are not causing errors. Of course this means, that data is changed because of technical reasons...

The fix is part of the next update (unfortunately today's update is already published...), please tell us in case you require the fix earlier.

Björn

Hello,

I ran in a very similar problem.

I my case, it was caused by the background database. When users entered the € sign, the DB stored did not stored the right char and returned the char #26. (in ASCII and UTF-8 the End of File - char)

Okay, at first I had to solve the "DB problem" by changing the charset, but are you able to catch these exceptions?

These exceptions where not normal exceptions (server side stacktrace), but they where real swing-client exceptions. So the client crashed totally.

Are you able to catch these ones to avoid these fatal errors?

Michael

Hi,

yesterday's fix consists of:
(1.) The special-characters are wiped out at server side (with corresponding warning message within in the log)
(2.) If the client crashes then the user can re-start (up to now the events were blocked)

Regards, Björn