Bug #47

srcBean.getDistinguishName does not works like expected

Added by Clément Oudot about 1 year ago. Updated about 1 year ago.

Status:Closed Start:04/05/2009
Priority:Normal Due date:
Assigned to:Jonathan Clarke % Done:

100%

Category:Core
Target version:1.1.0
Problem in version:

Description

Hello,

I try to use this to select branches :

lsc.tasks.inetOrgPerson.condition.create = srcBean.getDistinguishName().toLowerCase().matches(".*((ou=users)|(ou=admin)).*")

but the result of srcBean.getDistinguishName() is the generated DN and not the orginal DN, so the test does not work.

But when looking in log, we see the wanted DN because the logger use "id".


Related issues

related to Bug #51: condition are tested after modifications are calculated Closed 06/05/2009
related to Bug #64: LDAP objects do not contain the source DN Closed 09/06/2009

Associated revisions

Revision 244
Added by Jonathan Clarke about 1 year ago

Fixes #64. Fixes #47. Get the DN in the source object, and therefore copy it to the source bean

History

Updated by Jonathan Clarke about 1 year ago

  • Status changed from New to Feedback
  • Assigned to set to Clément Oudot
  • Target version set to 1.1.0
  • % Done changed from 0 to 50

Hi Clément,

I think this problem will be solved by the patch in issue #51. The idea is to use an intermediary bean where we make modifications (like changing the DN, and the result of syncoptions). Thus, srcBean will remain intact and identical to the source.

Could you apply the patch from issue #51 and rebuild lsc-core (mvn install), and let us know if this fixes the issue? We will probably commit the patch to the trunk soon, so check the issue #51 page, in case.

Thanks,
Jon

Updated by Jonathan Clarke about 1 year ago

The patch in issue #51 has been committed for a while now, so this issue should be solved too.

Updated by Jérôme Schell about 1 year ago

I have a similar problem in a Bean with the method getDistinguishName().

Example:

public static void mapMyAttribute(InetOrgPerson soc, IBean doc, String value) {
  String userDn = soc.getDistinguishName();
  ...
  LOGGER.debug("Handling " + userDn);
  ...
}

This displays:

Handling null

Don't know if the problem is related or not.
Tested with lsc-core from 2009.06.02.

Updated by Jonathan Clarke about 1 year ago

Jérôme Schell wrote:

I have a similar problem in a Bean with the method getDistinguishName().

Example: [...]

This displays: [...] Don't know if the problem is related or not. Tested with lsc-core from 2009.06.02.

Jérôme - This may mean that there is no DN for that object in your source. If you're going a db2ldap sync, that's likely.

Do you need to access the dstBean DN ? Or the generated DN from the lsc.tasks.TASKNAME.dn property ?

Let me know which, because we may need to make the generated DN accessible.

Updated by Jérôme Schell about 1 year ago

Jérôme - This may mean that there is no DN for that object in your source. If you're going a db2ldap sync, that's likely.

I've tried with db2ldap and ldap2ldap. Same problem, the result is null.

Do you need to access the dstBean DN ? Or the generated DN from the lsc.tasks.TASKNAME.dn property ?

Let me know which, because we may need to make the generated DN accessible.

Huum, not sure to get it right :)
I just need the DN of the entry being synchronized that's why I was using soc.getDistinguishName().
Nevertheless I solved this issue by constructing myself the DN but I thought that this method should return a valid result too ;)

Updated by Jonathan Clarke about 1 year ago

  • Assigned to changed from Clément Oudot to Jonathan Clarke

Jérôme Schell wrote:

I just need the DN of the entry being synchronized that's why I was using soc.getDistinguishName(). Nevertheless I solved this issue by constructing myself the DN but I thought that this method should return a valid result too ;)

You are referring to the getDistinguishName() method in the LscObject class. This bug refers to the method with the same name in the AbstractBean class. I have therefore opened Bug #64, about the bug you're seeing. Of course, it may well be directly linked to this bug...

Updated by Jonathan Clarke about 1 year ago

  • % Done changed from 50 to 100

Applied in changeset r244.

Updated by Jonathan Clarke about 1 year ago

  • Status changed from Feedback to Closed

Same as #64.

Also available in: Atom PDF