Thank you, bug reported: http://tools.lsc-project.org/issues/747
Le 2014-12-17 17:57, Marian Harbach a écrit :
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
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org
lsc-users mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-users
