Hi and good Morning, Emmanuel.
Good Morning, list-users.
Thx for your fast reply... your answers are what I expect ApacheDS to
act like. But there is one last question that I would like to ask
(question is at the end of this text, first some information ;-) ):
We need to use a so called DisIbmDsUserProvider.class which acts as the
interconnector between the Coremedia Content Management System and our
LDAP Server (First IBM TDS, now as mentioned, ApacheDS). This Connector
sends Requests against the ApacheDS Servers that should look like this:
DN: uid=00370029, cn=users, dc=VERWALTUNG, dc=DOUGLASHOLDING
But what it sends instead of this (I saw it in the logfiles of our
Content Server but cannot see it in ApacheDS logfiles) is the following:
DN: uid=00370029,%20cn=users,%20dc=VERWALTUNG,%20dc=DOUGLASHOLDING
Therefore, within the whitespace encoding to %20, the ApacheDS cannot
resolve this request. I did a small and simple test my own doing a
simple search against ApacheDS from within a simple java class. An error
is thrown:
javax.naming.InvalidNameException:
cn=users,%20dc=VERWALTUNG,%20dc=DOUGLASHOLDING: [LDAP: error code 34 -
Invalid root DN given : cn=users,%20dc=VERWALTUNG,%20dc=DOUGLASHOLDING
(0x63 0x6E 0x3D 0x75 0x73 0x65 0x72 0x73 0x2C 0x25 0x32 0x30 0x64 0x63
0x3D 0x56 0x45 0x52 0x57 0x41 0x4C 0x54 0x55 0x4E 0x47 0x2C 0x25 0x32
0x30 0x64 0x63 0x3D 0x44 0x4F 0x55 0x47 0x4C 0x41 0x53 0x48 0x4F 0x4C
0x44 0x49 0x4E 0x47 ) is invalid]; remaining name
'cn=users,%20dc=VERWALTUNG,%20dc=DOUGLASHOLDING'
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown
Source)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown
Source)
at javax.naming.directory.InitialDirContext.search(Unknown Source)
So, here comes the question:
Where, in ApacheDS source code, can I modify the sources so that
ApacheDS can recognize %20 and convert it to whitespaces? Is that possible?
Thanks for your patience with all my question.
TIA
Markus Pohle
Emmanuel Lecharny schrieb:
Hi Markus,
we are very happy to hear that you are using ADS 1.5 instead of IBM TDS :)
Some comments and informations are included further...
On 7/19/07, Markus Pohle <[EMAIL PROTECTED]> wrote:
Dear list,
I do have some maybe really silly questions and apologize in advance.
</snip>
The LDAP schema created in IBM TDS was like this:
DN: cn=users,cn=cms,dc=APPLICATIONS,dc=DOUGLASHOLDING
or
DN: cn=users, dc=VERWALTUNG, dc=DOUGLASHOLDING
or
DN: uid=00370029, cn=users, dc=VERWALTUNG, dc=DOUGLASHOLDING
We had to migrate this IBM TDS schema and had some problems with this in
the past. So... Here comes my questions:
- Is ApacheDS case-sensitive?
ADS is LDAP compliant, which means than we have implemented
SyntaxCheckers for attributeType. DC (domainComponent) are case
insensitive.
is there a difference for apacheds between
dc=APPLICATIONS,dc=DOUGLASHOLDING and dc=applications,dc=douglasholding?
None.
- Is ApacheDS whitespace-sensitive? is there a difference for apacheds
between DN: uid=00370029, cn=users, dc=VERWALTUNG, dc=DOUGLASHOLDING and
DN: uid=00370029,cn=users,dc=VERWALTUNG,dc=DOUGLASHOLDING?
None. WS are stripped around '=', ',' and '+'. For some
AttributeTypes, like SN or DC, multiple internal WS are also stripped.
For instance, 'dc = my own dc' is equivalent to 'dc=my own
dc'
Please, I would really appreciate any comments and replies to this.
Help is really appreciated!
Hope it helps !
