This is nearly identical to issue #11. ExchangeService.bindToFolder(Class, FolderId, PropertySet) will call bindToFolder(FolderId, PropertySet), which returns a Folder object. It is then tested to see if it is a Folder object, which we already know. It should be checked against Class instead.

Joda-Time is one of the most eminent libraries for Java date handling. I think it would be sensible for this project to make use of it, particularly in the ExchangeServiceBase class where most of the date-as-String to Date object conversions appear to be done.

An infinite call cycle can be triggered when working with ItemAttachments. It occurs within the change tracking code as follows:

ItemAttachment.ItemChanged() -> PropertyBag.changed() -> ComplexProperty.changed() -> ComplexPropertyCollection.changed() -> ItemAttachment.itemChanged()

There should be checks in place to prevent this sort of cycle from occurring.

Hi,

how is it possible to use this library in android? - i still get an VerifyError, when trying to use it.

Any experiences/ideas?

kind regards

When SimpleServiceRequest.execute() is called, it will call readResponse(HttpWebRequest), a private method in the same class. This class will close the passed HttpWebRequest in a finally block. If readResponse() throws an Exception, it will be caught in execute(), which will then attempt to extract information from the HttpWebRequest for debug purposes with ExchangeService.processHttpResponseHeaders(). However, with the response being closed, it will throw another Exception, which results in the "Connection not established" boilerplate that so many have seen. This needs to be fixed to ensure that the correct Exception message and stack trace is shown if one occurs.

This check will never be true, because obviously an Object is not a primitve.

You'll probably want to use ClassUtils.html#isPrimitiveWrapper or a self made function to avoid adding the dependency.

You can hit that code with something like this:

service.findItems(folder.getId(), new SearchFilter.IsEqualTo(extendedPropertyDefinition, (long) 1234), new ItemView(2));

and you'll get

Exception in thread "main" microsoft.exchange.webservices.data.ServiceXmlSerializationException: Values of type 'java.lang.Long' can't be used for the 'Value' attribute.
    at microsoft.exchange.webservices.data.EwsServiceXmlWriter.writeAttributeValue(EwsServiceXmlWriter.java:200)
    at microsoft.exchange.webservices.data.SearchFilter$RelationalFilter.writeElementsToXml(SearchFilter.java:1202)
    at microsoft.exchange.webservices.data.ComplexProperty.writeToXml(ComplexProperty.java:330)
    at microsoft.exchange.webservices.data.ComplexProperty.writeToXml(ComplexProperty.java:346)
    at microsoft.exchange.webservices.data.SearchFilter.writeToXml(SearchFilter.java:113)
    at microsoft.exchange.webservices.data.FindRequest.writeElementsToXml(FindRequest.java:128)
    at microsoft.exchange.webservices.data.ServiceRequestBase.writeBodyToXml(ServiceRequestBase.java:142)
    at microsoft.exchange.webservices.data.ServiceRequestBase.writeToXml(ServiceRequestBase.java:291)
    at microsoft.exchange.webservices.data.ServiceRequestBase.buildEwsHttpWebRequest(ServiceRequestBase.java:752)
    at microsoft.exchange.webservices.data.ServiceRequestBase.validateAndEmitRequest(ServiceRequestBase.java:709)
    at microsoft.exchange.webservices.data.SimpleServiceRequestBase.internalExecute(SimpleServiceRequestBase.java:47)
    at microsoft.exchange.webservices.data.MultiResponseServiceRequest.execute(MultiResponseServiceRequest.java:142)
    at microsoft.exchange.webservices.data.ExchangeService.findItems(ExchangeService.java:928)
    at microsoft.exchange.webservices.data.ExchangeService.findItems(ExchangeService.java:981)

The ExchangeService.internalGetAttachments() (line 1541, currently) is broken. This method does some truly ridiculous things with generics and untyped collections. I'm not even sure what the idea behind all of this was. The generics muckery resulted in a bug. Essentially, there's an unnecessary block of code in which we wind up with an untyped ArrayList with a List inside due to using both the untyped ArrayList and add() instead of addAll().

EWS is using a EOL version of httpclient for which we won't be getting any security updates. Please upgrade EWS to use Apache http components release.

When ExtendedPropertyDefinition parses the SOAP response, it uses Integer.getInteger(attributeValue, 16) to parse the tag property, if present. This method does not parse numbers in an 0x0... hexadecimal format and will incorrectly parse all tags as 16. Integer.decode() should be used as this will read hexadecimal numbers.

It appears that EwsUtilities.getPrintableTypeName() is supposed to nicely print "List" instead of the usual debug output, but it winds up throwing Exceptions instead. I'm not even going to try describing what this method was attempting to reach this goal, but needless to say, it doesn't work at all. Either this should be implemented correctly if possible or removed entirely.

This is nearly identical to #31. RemoveFromCalendar will invoke the super constructor with Item.getService(), then null check it on the next line, which is pointless as it would have already thrown an Exception if the Item was null.

We are getting a NullPointerException in our usage of the Java EWS API in some client environments. We are currently using version 1.1.5 but have tried 1.2 as well. I was hoping someone could shed some light for us on how to further investigate the underlying issue.

Our product is a web application written in CFML (on top of Java) which is leveraging this Java API. I can step through our code and it looks like a connection to the EWS is being made, however when we make a call on a mailbox to "FindAttachments" it throws this exception.

Testing these environments via the MS tool https://testconnectivity.microsoft.com/ passes.

Is there a Java Client readily available that I can test server connection credentials with and test API method calls? I'm hoping to get to the source line in the API that is causing the issue to understand what is triggering it. It feels like it must be something environmental as we have a number of customers using the current implementation without issues and connecting to Office 365 or local Exchange servers. Any help would be greatly appreciated.

There is a getIsMeeting() but there is no direct possibility to set it.

Fixed by #63

In AttachmentCollection.addItemAttachment(Class), a check is performed to see if the class is attachable. It checks to see if the class has any declared fields, which is incorrect as Class.getDecaredFields() will not return inherited fields and there are attachable classes that do not declare their own fields, but rely on those in parent classes. There is an @attachable annotation that is present on all attachable objects. It should be checking against this instead.

Convert.ToBase64String takes a byte array as an argument and simply returns a toString() on said array, which will not produce the desired result. This needs to be converted to a Base64 String prior to returning.

All 591 types in this library are located in the same package. This really doesn't help understanding how the library is organized.

MeetingMessage.getSchema() returns an EmailMessageSchema when it should return the MeetingMessageSchema. This affects the child classes of MeetingCancellation and MeetingResponse. MeetingRequest is not affected.

The issue is that both aforementioned child classes rely on MeetingMessage to return a schema. MeetingMessage.getSchema() calls MeetingMessageSchema.getInstance(). This method is not present on MeetingMessageSchema and goes up to EmailMessageSchema.getInstance(), which returns an EmailMessageSchema for the two classes, omitting additional properties from MeetingMessageSchema.

MeetingMessageSchema should return its own instance directly and not rely on its parent class.

Is this licensed under MIT or are all rights reserved by Microsoft? There seems to be some confusion on whether this is actually MIT since all source files (including the license.txt) indicate everything is copyright Microsoft with all rights reserved.

If you look at the XML response to a request for calendar items, where there is at least one item with a recurring rule, you may see a date like the following:

2014-07-07+01:00

which I have seen given as the value for the StartDate element of an EndDateRecurrence element. An exception is thrown when trying to parse this date.

I believe it's down to the fact that the basic java.util.Date API doesn't deal well with offsets specified in this way. Joda-Time may be a good way to go.

I keep getting this error while trying to connect.
Any idea ?

Am getting following error while Could you please help on this.

Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
at sun.security.validator.Validator.validate(Validator.java:260)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:105)
at microsoft.exchange.webservices.data.EwsX509TrustManager.checkServerTrusted(EwsX509TrustManager.java:62)
at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:865)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1351)

In several areas of the API, byte[] and Byte[] are used interchangeably. It doesn't throw a compiler error due to the lack of generics in many places, so exceptions occur at runtime instead. While primitives and their associated objects can be used interchangeably, arrays cannot. MapiTypeConverter, MapiTypeConverterMapEntry, and UserConfigurationDictionary are culprits. I would recommend this be changed to primitive byte arrays across the board.

The constructor for SuppressReadReceipt takes an argument of an Item. It will call super(Item.getService()), and then it will null check the Item on the next line. This is pointless as an Exception will be thrown when invoking super() if the Item is null.

I think there should be some coding standards for this projects. For example:

• Currently, tabs and spaces are used interchangeably, which makes the code hard to read.
• The line length seems a little bit short.

In AttachmentCollection.validate(), there is a point at which attachments are cast to FileAttachment without a typecheck. This region is to check to see if the attachment is a contact photo in new attachments, but it is possible for an ItemAttachment to be processed. A type check should be implemented.

Following on from issue #45, the end property of the EndDateRecurrenceRange is null, despite the XML parsing ostensibly working.

This problem has been referenced before, on StackOverflow:

http://stackoverflow.com/questions/11200822/cant-get-recurrence-end-date-using-ews-java-api

along with a possible fix.

The validatePropertyAccessMethod in UserConfiguration should only throw a ProperyException if propertiesAvailableForAccess does NOT contain the given property and not the other way round.

From the old EWS Java API blog post. User "Stefan" reported this issue with the comments quoted below. I've reached out to Stefan to see if he can submit a pull request.

Jan 29th, 2013
I'm having a problem downloading huge attachments on system with limited memory, Since everything is loaded into memory first - even if I use IFileAttachmentHandler or load(stream). Is there a possibility to directly stream the attachment or the whole item to an outputstream without downloading everything to memory first?

Feb 4th, 2013
I just patched it for attachment and mime-content streaming - if someone is interested send me an mail to selbitschka [at] gmail [dot] com. I also would submit it as patch if someone tells me where.

In ExtendedPropertyCollection.tryGetValue(Class, ExtendedPropertyDefinition, OutParam), there is a conditional to see if the passed Class argument is assignable from the passed ExtendedPropertyDefinition.getType(). The conditional is backward. It will throw an Exception if it is assignable and will set the value in the passed OutParam if it is not. It should be the opposite, throwing the Exception if it is NOT assignable and setting the value in the OutParam if it IS assignable.

I can not able to list out shared folder using API. Need to provide a way for that.

E.g. [email protected] is one user who is creating a calender and shared to [email protected]. Now I want to retrieve list of shared calendar using [email protected]'s credential which is shared with him. Can any one help me how we can do it?

Is this bug or limitation?

In EwsXmlReader.isStartElement(XmlNamespace, String), an == operator is used to compare the current namespace prefix against EwsUtilies.getNamespacePrefix(XmlNamespace) as well as the current namespace uri against EwsUtilities.getNamespaceUri(XmlNamespace). The same is done in EwsXmlReader.internalReadElement(XmlNamespace, String, XMLNodeType). Even if we know that these will be the exact same Object, the .equals() method should be used instead for safety and clarity.

Integrate github repository with Travis to build and run tests for commits and pull requests.

As far as I can tell the library doesn't allow you to construct a StreamingSubscription from a pre-existing subscriptionId. This can be useful if you want to reusing a particular subscription between processes.

For the API goes it looks like we could make a public constructor for this on StreamingSubscription:

public StreamingSubscription(ExchangeService service, String subscriptionId) {
 // ...
}

Or add a build method to ExchangeService:

public buildStreamingSubscription(String subscriptionId) {
  // ...
}

I'm happy to create a PR for either of these options.

When invoking Base64EncoderStream.encode(), it will can produce a String containing characters outside of the Base64 alphabet. This should be fixed, calls replaced with Base64Encoder.encode(), or replaced entirely with a third-party library.

There is an issue with timezones of the datetime objects returned by this version. We had an older version EWS and had perfect times set for GMT +3. Now all GMT +3 times are assumed as GMT and we get 3 hours early datetimes. I tried to compare my old version and your version and couldnt pinpoint the problem. Could you address this asap?

Thanks =)

In ExchangeService.bindToItem() (line 1428, currently), the parameter Class is passed. The method uses the generic bindToItem() to retrieve an item, then does a type check and cast down to TItem. However, the type check is:

if (result instanceof Item)

This is incorrect as we already know it's an item. It should be type checking against Class.

According to the code at EndDateRecurrenceRange.tryReadElementFromXml(), the value is read as a date-time, when in fact, the types.xsd file declares that this type is an xs:date.

Consequently, should it use the same method as its superclass does when trying to read the start date of the recurrence range, i.e. read it as a date, not a date-time?

The hierarchy starting with the interface Callback is obviously incomplete and non-functional. AbstractAsyncCallback works with a mutable static boolean to determine if it should run the child method of processMe(), and when it does, it sets the boolean and sleeps for one second.

Not only is the static variable usage in a class designed for multithreading horrific, but the whole thing doesn't even do much of anything. I'm guessing that this was test code that was never completed and left in place. This hierarchy should be revised. I'd recommend flattening it and allowing for easy extension to add desired behavior.

The class MeetingMessage.java should expose its properties via getter methods, as per the types.xsd, in a similar fashion to the way in which its parent class and other classes do.

It would be great if the artifacts were deployed to Maven central, removing the need to manually build and install the project on each workstation/CI server.

This isn't exactly a bug, but it is an incomprehensible use of annotations that, while functional, is still very, very wrong.

Take a look at the @EwsEnum and @RequiredServerVersion annotations in, for example, the FileAsMapping enum. The annotations are used to store additional data for each value. This is used in EwsUtilities, which builds a convoluted series of Maps to map out which enums and specific values have the annotations so it can tell if this value has a schema name or a required server version.

This whole mess is completely unnecessary. Enums in Java can extend interfaces, contain variables, and overload constructors. All of the above can easily eliminate the need for these annotations and the code that handles them.

When using a PropertySet with multiple Extended Properties and requesting an Item from Exchange, only one ExtendedProperty is set on the object, even though the server is returning multiple in the SOAP response.

This is due to the way Extended Properties are placed into an ExtendedPropertyCollection and then placed into the PropertyBag. Each ExtendedProperty is parsed, placed into an ExtendedPropertyCollection, and then placed into the PropertyBag, which essentially wraps a HashMap. Each Collection overwrites the previous one, leaving on one ExtendedProperty on the Item.

On updating attachments in appointments it doesn't update.
you have to call the update at least twice .

When the EwsXmlReader encounters empty spaces between tags, it will improperly parse and wind up throwing an Exception. This does not apply to empty tags if there is no whitespace between them. The read() method deliberately skips whitespace, but this is not taken into account in EwsXmlReader.readValue(). It will ensure that it's reading a start element, then call read(). This will skip the space and go to the end element. It checks XmlEvent.isCharacters(), which will return false, and it throws an Exception instead. The XML parsing needs to handle whitespace correctly.

ServiceObject.getObjectFromPropertyDefinition(PropertyDefinitionBase propertyDefinition) is a non-functional mess. There are two unchecked casts that can result in an Exception and a null check that is pointless as the object would already have to be null at that point to even reach the conditional in the first place, and in certain cases, and it returns very different and incompatible types depending on the path. I could describe it in detail, but it's pretty self-evident when you look at the code. This should be cleaned up and functional.

Task.setPercentComplete(String value) is a basic setter, but it calls PopertyBag.setObjectFromPropertyDefinition(TaskSchema.PercentComplete, value). TaskSchema.PercentComplete is a DoublePropertyDefinition. The setter should take a Double argument, not a String.

Hi good day !!

what are the requirements of the java api ?

• Java Version ?
• Libraries ?

Thanks and we are in contact.

Please add Exchange2013 as enum value to ExchangeVersion.java or else users cannot connect to Exchange2013

The ExtendedPropertyDefinition.equals(Object) method does an incorrect comparison. It compares Integers (the tag variable) using the == operator instead of .equals().