LDAP group handler should escape dollar signs in values when used with regexps
eGroupware creates the postalAddress and homePostalAddress attribute compositing the various street, city, zip, etc.. using some dollar signs ($).
Openfire works without a problem, and I and the other users can login and send messages and such. However, when I tried to configure some transports to ICQ and MSN, the transports didn't work and I kept getting in the debug log the following entries:
2008.04.01 21:45:10 LdapVCardProvider: Getting mapped vcard for rob.mau
2008.04.01 21:45:10 Exception while processing packet: java.lang.IllegalArgumentException: Illegal group reference
I'm no java programmer, but I've searched google for "Illegal group reference", and the first entry is this: http://cephas.net/blog/2006/02/09/javalangillegalargumentexception-illegal-group-reference-replaceall-and-dollar-signs/
There the blog's author explains that when using the replaceAll method of the String object, the first argument is considered a regular expression, and any occurrence of $ in the second parameter is taken as a backreference to a parenthesis group inside the regular expression in the first. Too bad this isn't the case, and we get the "Illegal group reference".
I suspected that in the mapping of LDAP attributes to a user vcard there's a String.replaceAll that's used, and that when it tries to replace postalAddress it get confused by the dollar sign before the ZIP code.
As a test, I removed the $ signs in my user record, and I was able to use the transport without a problem
So I'd say that LdapVCardProvider (don't know if it's local to the IM Transport plugin or a system function of Openfire) does not escapes correctly the $ signs it may find in the LDAP records that it tries to map to a vcard for the user logging in the Transport.
For egroupware there's a "best fix" to NOT use "postalAddress" and "homePostalAddress" as "Home street address" and "Business street address" in the user profile vCard definition: this way there are no $ signs in the vcard mapping and no errors.
But this problem could bite for every LDAP field that gets mapped in the user vcard if in some field you have a $ sign followed by a number. The fix should be to escape every dollarsign with a backslash (and this probably has been already done for the core, since it works even with the addresses full of dollarsigns)