powered by Jive Software

Attention: Folk who wrote VCard providers for Openfire

Hi folk!

In working with the LDAP vCard provider and allowing avatars to be stored in the database, we found a big shortcoming in the vCard provider handling. Namely, if the provider needed to tweak the vCard during an update or create, the tweaked card would not be cached. Instead, the original card that the user submitted would be cached. In our case, this was not good because the LDAP provider is primarily read-only and by caching exactly what the user submitted, we were allowing fields to be seemingly overwritten that shouldn’t have been. (at least until the cache was cleared up)

So, we made a change to the VCardProvider interface. Instead of updateVCard and createVCard methods having a void return, they now have an Element return, and are expected to return a vCard to be cached. If you don’t do anything to the vCard, it’s a simple matter of returning the vCard that was passed in as an argument. In our case, we’re returning the vCard after modifying it a tad (basically, we’re replacing all of the non-PHOTO elements with what they are coming out of LDAP).

You can see the interface changes here:

http://www.igniterealtime.org/fisheye/browse/svn-org/openfire/trunk/src/java/org /jivesoftware/openfire/vcard/VCardProvider.java?r1=8651&r2=9727

This change will be in place for Openfire 3.4.4, so please be aware that you will need to adjust any vCard providers you may have written. There will be a note about it in the release notes and such, but I wanted to post the details here.