The problem here is that cloneSrcBean is called twice, such that effectively
itmBean = cloneSrcBean(cloneSrcBean(srcBean)). Therefore, the mainIdentifier
statement from below (srcBean.getMainIdentifier().replace(",o=Org","") +
",ou=Org,dc=Uni,dc=de”) is applied twice to the DN. Hence it will in the first
execution replace ",o=Org" with ",ou=Org,dc=Uni,dc=de” and then, in the second
execution, the replace will have no effect as “,o=Org” will no longer be found
but the string addition will still be executed and then result in
",ou=Org,dc=Uni,dc=de,ou=Org,dc=Uni,dc=de” as the DN in the itmBean. Passing
srcBean instead of itmBean at the mentioned location will avoid this (and I
don’t really see the point of cloning it twice anyway).Marian > On 17. Dec 2014, at 17:51, Raphaël Ouazana-Sustowski > <[email protected]> wrote: > > That's strange. I can reproduce the other issue with the configuration for > this issue, but not this issue. This issue appears only when trying to > replace DN with commas in RDN, which seems related to the other issue. And I > don't see how the fix in BeanComparator could change anything to that. > > Regards, > Raphaël Ouazana. > > Le 2014-12-17 16:50, Marian Harbach a écrit : >> Nope, it's different. >>> Am 17.12.2014 um 16:41 schrieb Raphaël Ouazana-Sustowski >>> <[email protected]>: >>> Hi, >>> Is this issue related/solved by your other post on the mailing list? >>> Regards, >>> Raphaël Ouazana. >>> Le 2014-12-15 12:55, Marian Harbach a écrit : >>>> Sure. How about data sources though? are there any standard sources >>>> that I need to base this on? Otherwise, here is the task part of the >>>> config that syncs from one OpenLDAP to another. >>>> <task> >>>> <name>task2to1</name> >>>> <bean>org.lsc.beans.SimpleBean</bean> >>>> <ldapSourceService> >>>> <name>src-service</name> >>>> <connection reference=“srv2" /> >>>> <baseDn>o=Org</baseDn> >>>> <pivotAttributes> >>>> <string>mail</string> >>>> </pivotAttributes> >>>> <fetchedAttributes> >>>> <string>cn</string> >>>> <string>sn</string> >>>> <string>objectClass</string> >>>> <string>mail</string> >>>> </fetchedAttributes> >>>> <getAllFilter>(objectClass=inetOrgPerson)</getAllFilter> >>>> <getOneFilter>(&(objectClass=inetOrgPerson)(mail={mail}))</getOneFilter> >>>> <cleanFilter>(&(objectClass=inetOrgPerson)(mail={mail}))</cleanFilter> >>>> </ldapSourceService> >>>> <ldapDestinationService> >>>> <name>dst-service</name> >>>> <connection reference=“srv1" /> >>>> <baseDn>ou=Org,dc=Uni,dc=de</baseDn> >>>> <pivotAttributes> >>>> <string>mail</string> >>>> </pivotAttributes> >>>> <fetchedAttributes> >>>> <string>cn</string> >>>> <string>sn</string> >>>> <string>objectClass</string> >>>> <string>mail</string> >>>> </fetchedAttributes> >>>> <getAllFilter>(objectClass=inetOrgPerson)</getAllFilter> >>>> <getOneFilter>(&(objectClass=inetOrgPerson)(mail={mail}))</getOneFilter> >>>> </ldapDestinationService> >>>> <propertiesBasedSyncOptions> >>>> <mainIdentifier>srcBean.getMainIdentifier().replace(",o=Org","") + >>>> ",ou=Org,dc=Uni,dc=de"</mainIdentifier> >>>> <defaultDelimiter>;</defaultDelimiter> >>>> <defaultPolicy>FORCE</defaultPolicy> >>>> </propertiesBasedSyncOptions> >>>> </task> >>>> Hope this helps! >>>> Marian >>>>> On 15. Dec 2014, at 12:50, Clément OUDOT <[email protected]> >>>>> wrote: >>>>> 2014-12-15 12:25 GMT+01:00 Marian Harbach >>>>> <[email protected]>: >>>>>> Hi Clement, >>>>>> I finally came around to look at this again. The issue seems to be >>>>>> that the mainIdentifier javascript is applied twice during >>>>>> modification checking in the BeanComparator. This patch fixes the >>>>>> problem for me: >>>>>> Index: BeanComparator.java >>>>> =================================================================== >>>>>> --- BeanComparator.java (revision 2025) >>>>>> +++ BeanComparator.java (working copy) >>>>>> @@ -158,7 +158,7 @@ >>>>>> IBean itmBean = cloneSrcBean(task, srcBean, dstBean); >>>>>> // get modification type to perform >>>>>> - LscModificationType modificationType = >>>>>> calculateModificationType(task, itmBean, dstBean); >>>>>> + LscModificationType modificationType = >>>>>> calculateModificationType(task, srcBean, dstBean); >>>>>> // if there's nothing to do, just return >>>>>> if (modificationType == null) { >>>>>> calculateModificationType() clones the srcBean parameter again and >>>>>> in the current version the already-cloned itmBean is passed in. >>>>>> Thus, in calculateModifications, the DN is modified twice and >>>>>> fails the equals check, causing the modrdn modification type. Can >>>>>> somebody verify this? >>>>> Could you send us a minimal configuration that reproduces the >>>>> problem? >>>>> Clément. >>>> -- >>>> Marian Harbach >>>> Research Associate >>>> Distributed Computing and Security Group >>>> Leibniz Universität Hannover >>>> Schloßwender Str. 5, 30159 Hannover, Germany >>>> Tel. +49 (0) 511 762 79 9038 >>>> _______________________________________________________________ >>>> Ldap Synchronization Connector (LSC) - http://lsc-project.org >>>> lsc-users mailing list >>>> [email protected] >>>> http://lists.lsc-project.org/listinfo/lsc-users -- Marian Harbach Research Associate Distributed Computing and Security Group Leibniz Universität Hannover Schloßwender Str. 5, 30159 Hannover, Germany Tel. +49 (0) 511 762 79 9038
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________________________ Ldap Synchronization Connector (LSC) - http://lsc-project.org lsc-users mailing list [email protected] http://lists.lsc-project.org/listinfo/lsc-users
