PicketLinkIDMOrganizationServiceImpl's support for LDAP users not created through portal

[gazda]

Gentlemen,

as reported in http://forum.exoplatform.com/portal/public/classic/forum/topic/topicaa140aaf7f00000101ea25a3c6692ead org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl from exo.portal.component.identity-3.1.8-PLF.jar does not seem to handle those users well which either preexist in LDAP or which are created with external tools.

For such users

  javax.jcr.PathNotFoundException: Node not found /Users/webmaster/Private/Favorites

is thrown, because UserEventListeners which initialize the named and other JCR pathes, were newer triggered for those users.

I could fix it through subclassing org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl and org.exoplatform.services.organization.idm.UserDAOImpl. My UserDAOImpl overrides the authenticate(String, String) method. The relevant part was changed from

if (authenticated)
 {
 UserImpl userImpl = (UserImpl)user;
 userImpl.setLastLoginTime(Calendar.getInstance().getTime());
 saveUser(userImpl, false);
 }

to

if (authenticated) {
                 boolean firstLogin = user.getLastLoginTime() == null;
                 
                 UserImpl userImpl = (UserImpl) user;
                 userImpl.setLastLoginTime(Calendar.getInstance().getTime());
                 
                 if (firstLogin) {
                     /* broadcast to make sure that the user gets initialised */
                     createUser(userImpl, true);
                 }
                 else {
                     saveUser(userImpl, false);
                 }
}

I agree that

firstLogin = user.getLastLoginTime() == null 

is probably not the universal way to test if the given user was initialized in the JCR. But it seems to be enough for my deployment, where all users come from LDAP and none of them is created through the portal.

I must admit, that on the first login of every user I get a javax.naming.NameAlreadyBoundException. However, it is catched immediatelly and it makes no harm.

What I have produced here is more a workaround than a perfect solution. I can live with it but I would still like to know if you see some kind of need for PicketLinkIDMOrganizationServiceImpl to support LDAP users which are not created through portal.