I've been trying to solve a problem that we've been running into regarding synchronization between our XMPP Openfire server database, and our Liferay database.
Currently, we are still in development, so we are constantly blowing away and rebuilding our Liferay database with new data. This sometimes causes the userId's of our initial test users to change from one iteration to the next. Which in turn causes them to have new XMPP accounts created with that new userId, and then block them from access to their old accounts.
I do see that this shouldn't be the case in a production environment since the database shouldn't be rebuilt regularly, however, I do find it odd that the use of the userId attribute is hardcoded into the portal framework. This could potentially cause headaches if a database restructuring were in fact needed.
There is the possibility to change the LoginPostAction.java in EXT so that it calls:
MessagingUtil.createXMPPConnection(ses, user.getScreenName());
instead of
MessagingUtil.createXMPPConnection(ses, user.getUserId());
However, the use of the userId is scattered throughout the MessagingUtil.java file in the portal core, such as in the addRosterEntry method.
Was there a reason that the userId was especially chosen over the screenName? If not, then might it be possible in a future version to give the EXT developers more control over what is used as the XMPP account ID?
