#52 Table Editor bugs when several names for same attribute



In an LDAP schema there may be defined several names
for the same attribute, e.g.

RFC 1274 + RFC 2247

attributetype ( 0.9.2342.19200300.100.1.25
NAME ( 'dc' 'domainComponent' )
DESC 'RFC1274/2247: domain component'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch

where 'dc' and 'domainComponent' name the same

An objectclass definition in a schema may mention the
attribute by either of the available names, e.g. by the
second one:

objectclass ( 0.9.2342.19200300.100.4.13 NAME 'domain'
MUST domainComponent
MAY ( associatedName $ organizationName $

Table Editor lists all available attributes on an entry.

If LDAP server uses another name when returning the
list of attributes, not the one mentioned in schema, the
Table Editor does not recognize it for being the same

If the attribute is mandatory, but was returned by the
server using an alternate name, then when editing the
entry the Table Editor shows the mandatory attribute as
having no value, and does not allow submitting the
changes, saying "All Mandatory Attributes must have

In my case, 'domainComponent' attribute was shown as
having no value, but a 'dc' attribute was there with the
value I expected.

Copying the value from 'dc' to 'domainComponent' also
resulted in an "Unable to perform Modify operation" error
message (LDAP: error code 20, value #0 already exists).

Moving the value from 'dc' to 'domainComponent',
where 'dc' remains in the table with an empty value,
resuted in an "Unable to perform Modify operation" with
java.lang.NullPointerException being shown in details.

Thus there are no ways to edit/update this entry using
the Table Editor.

Similar issues occur when you trying to create an entry,
using an alternate name for the attribute. In this case,
when you create a 'domain' entry using RDN 'dc=xxx'
instead of 'domainComponent=xxx'.


  1. Modify the schema definition file on the server, so
    that all the definitions used the same name of the


OpenLDAP 2.2.6-37.19 on SuSE Linux Ent. 9
JXplorer 3.1 rc5 on Windows

schemas invloved:
1. core.schema (defines 'dc' attributetype)
2. cosine.schema (defines 'domain' objectclass with a
MUST attribute 'domainComponent')

Steps to reproduce

  1. Create an entry with object classes 'domain' and 'top'
    and RDN: domainComponent=xxx. A Table Editor is
    shown. Press "Submit" to create the entry.

  2. Refresh the tree (View > Refresh).

Refreshing is required, because DN of the entry will now
show up having a 'dc=' component instead of
having 'domainComponent='. (Without refreshing there
will be other bugs when editing / submiting).

  1. Select the created entry. Shitch to the Table Editor
    view. You will see the following attributes:
    domainComponent (in bold): (no value, empty cell)
    objectClass (in bold): domain
    objectClass (in bold): top
    dc (in plain text): abc (bold, in blue color, as part of DN)

And below are 'associatedName' and other attributes, in
plain text, with no values.

  1. Press "Submit". You will see a message box saying "All
    Mandatory Attributes must have values!".

I have found no ways to submit changes to this entry,
using the Table Editor.

  1. Create a sibling 'domain' entry at the same level of
    the tree. In the new entry dialog ("Set Entry Object
    Classes") I am suggested to enter RDN as "dn=".

Doing so shows up a Table Editor for the new entry,
with a value for 'dc' attribute and no value
for 'domainComponent'.

I have found no ways to submit the values to create
the new entry. ( Copying the value of "dc" attribute
into "domainComponent" attribute results in "Unable to
perform Modify operation." with "LDAP: error code 20 -
attribute 'dc' provided more than once". Copying the
value of "dc" attribute into "domainComponent" attribute
with setting "dc" attribute to an empty value results
in "Unable to perform Modify operation." with
dc=,dc=ldap2,dc=rian,dc=net: [LDAP: error code 34 -
invalid DN]
; )

The workaround is to ignore suggested "dc=" when
creating the entry and use "domainComponent=" instead.


  • Brad Mace

    Brad Mace - 2005-02-02

    Logged In: YES

    I've noticed this problem as well since 3.0. It cripples
    what woudl otherwise be an excellent program

  • Christopher Betts

    Logged In: YES

    remember you can always turn schema checking off in the options, in
    which case it should work fine :-)!

    Long term I'll change the schema checking to use OIDs rather than the
    display name for checking this sort of stuff...

  • Christopher Betts

    Logged In: YES

    By the way, this is identical to the existing bug 787908 ... as is the
    comment about the workaround :-)


Log in to post a comment.