Smack 3.2.x with XCP 5.8 DelayedInformation always shows current time

I’m using Smack 3.2.1 to communicate with Cisco (formerly Jabber) XCP 5.8. It works pretty well but XCP 5.8 returns delayed delivery timestamps using an older format that is similar to, but not exactly, what Smack is looking for. The result is that when a user joins a MUC room all messages have the current time as their timestamp regardless of when the message was actually sent.

XEP-0091 (http://xmpp.org/extensions/xep-0091.html#time) says the timestamp should look like this: CCYYMMDDThh:mm:ss.

XCP 5.8 returns a stamp that looks like this: CCYYMMDDThh:mm:ss.millis (e.g., 20120507T12:13:14.123456). Note the inclusion of a millisecond component to the timestamp.

Anyway, this was causing Smack to miss the originally sent stamps XCP was setting which resulted in the provider defaulting to the current time. I created a custom build for us to use that modifies DelayInformationProvider.java line 75 from this:

formats.put("^\d+T\d+:\d+:\d+$", DelayInformation.XEP_0091_UTC_FORMAT);

to this:

formats.put("^\d+T\d+:\d+:\d+(\.\d+)?$", DelayInformation.XEP_0091_UTC_FORMAT);

I realize this isn’t 100% in compliance with what XEP-0091 specifies (though it does align with XEP-0082 in terms of optional millis), so it might be better to define another format rather than tacking it onto the XEP-0091 format regex.

Regardless, I think this would be helpful if this were included in a future release.

Even XEP-0091 is marked obsolete, so I don’t see any point in modifying the code to handle a custom use case for an obsolete spec.

I suggest you simply write your own provider to handle the extension though, instead of creating a custom build. Then you just need to replace the default provider with your own.

You raise a good point but we are unable to migrate to a platform that supports a more recent set of specs at the moment. That said, there are a fairly large number of XCP 5.8 installations still in use. My hope was that since it’s such an easy fix, relatively easy to test, and can potentially benefit a fairly significant number of users that it would make it into a future release.

Also, can you provide more details on how I’d write a custom provider to replace something that is loaded by default? The ProviderManager JavaDocs say “If multiple provider entries attempt to register to handle the same element name and namespace, the first entry loaded from the classpath will take precedence…”. In other words, the DelayInformationProvider is already registered to handle this extension and is fine most of the time. In order to get my custom handler to work, I’d need to remove this and replace it with mine (I’m assuming I’d replace the entry for Delayed Delivery providers in smack.providers at minimum). This basically takes me back to maintaining a custom build.

Just add a call to ProviderManager.addExtensionProvider() in your code to set the extension provider. This will override whatever is already loaded from the *smack.providers *file.

OK, thanks. I’ll figure something out.