I dont know if this is just because of the classes all beeing stored to in one big package. But I have seen lots of classes in this where I was wondering if the visibility is declared as it is by design.
hi there, I would be happy if anybody could assist in finalizing #139. There is currently a large number of violations shown by mvn checkstyle:check see travis-ci log for details (starting at line 1118 which needs to be expanded). In this case our #4 Coding-standard doesnt match the google-style, which is bad :fire:
Hi there, I have a newbie question about the EWS Java API. I couldn't find any solution elsewhere so either nobody has the problem or the fix is so simple that nobody bothers to post it (or I'm not good at searching). Per http://technet.microsoft.com/en-us/library/gg585107(v=exchg.80).aspx the EWS can return invalid XML characters in the response. This will cause exceptions in the EWS Java API similar to: microsoft.exchange.webservices.data.ServiceRequestException: The request failed. Illegal character entity: expansion character (code 0x1a) not a valid XML character. The obvious solution (also suggested in the TechNet article) is to skip XML validation. I'm using the woodstox XML parser. I have no idea how to disable that validation. I tried a filter input stream to just replace invalid characters but failed (wrong spot I guess) and it might be too low level in the stack to do this. Has anybody found a solution for this problem?
My scenario is number 2 - receive invalid XML from the server. How can I configure the Exchange server to only return valid XML? No experience with Exchange administration here - just tasked to write a client using the EWS Java API. From the TechNet article it sounds that invalid XML is expected behavior. I found a fork on GitHub that attempts a fix (didn't check it out) using a modified version of woodstox: scottbessler/ewsjavaapi@39d3003 Can the EWS Java API be modified to work around this?