These are chat archives for OfficeDev/ews-java-api

12th
Dec 2014
tvirtualw
@tvirtualw
Dec 12 2014 13:42
@MikeN123 I appreciate the encouragement :). Unfortunately it's not my decision to make - I just have to live with the fallout.
tvirtualw
@tvirtualw
Dec 12 2014 13:52
To sum up our research about the invalid XML at this point: From MS' perspective it's understandable that they handle it this way. External email is received by Exchange with special characters and Exchange does not change its contents and just passes it on as-is to any client. I feel that's correct behavior and Exchange is not to blame for it. So eventually any EWS client somehow has to deal with. I just wonder why I can't find any good documented solutions or approaches of handling for this scenario with the Java API. Is it really so rare? Anyway, in our client we want to modify the content and replace each invalid XML char with a space. First approach is to patch the XML parser using javaassist - that seems to work for some versions of woodstox. Second approach is to build a FilterInputStream that checks for invalid XML chars (their encodings) and removes/replaces them from/in the stream, e.g. in microsoft.exchange.webservices.data.SimpleServiceRequestBase#readResponse. The second might be the preferred solution as it does not depend on specific XML parser (versions). But at this point I feel the XML parser patching solution seems more safe in terms of side effects because it is applied at the "right" level. Any feedback from the experts is very welcome :)