You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Gianmaria Clerici <gc...@bridgestream.com> on 2005/10/19 00:52:22 UTC
DnParser
NormalizationService will use org.apache.ldap.common.name.DnParser to
normalize a Name.
For instance, if my Name looks like this:
ou=Sub Production V,bsiViewName=Direct Report View
It will return this:
ou=sub production v,bsiViewName=direct report view
As you can see it will replace the 2 spaces before the V with one space.
Is this the correct behavior ?
I will need to look up an object using the normalized value (down in my
partition code), but it's a bit more challenging if the spaces have
been, partially, removed.
Thanks
Re: DnParser
Posted by Alex Karasulu <ao...@bellsouth.net>.
Ersin Er wrote:
>I think it's better to redefine LdapName as Sun did in 5.0 and
>normalization should be a seperate process. (Emmanuel, I favor my
>previous proposal.) This will also provide compatitibility with Java
>SE for future versions of ApacheDS.
>
>
Does your proposal differ from Emmanuel's idea of separating
normalization from parsing. Could you restate it? I might have missed
it sorry.
Also Emmanuel I guess your 3 passes to parse and normalize makes sense
for optimization. We do need to solve the DN bottleneck in the server
so I'm eager to optimize.
Cheers,
Alex
Re: DnParser
Posted by Ersin Er <er...@gmail.com>.
I think it's better to redefine LdapName as Sun did in 5.0 and
normalization should be a seperate process. (Emmanuel, I favor my
previous proposal.) This will also provide compatitibility with Java
SE for future versions of ApacheDS.
See: http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/LdapName.html
On 10/19/05, Emmanuel Lecharny <el...@apache.org> wrote:
> <snip/>
> > >8.1 :
> > >...
> > >When performing the caseIgnoreMatch, caseIgnoreListMatch,
> > > telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
> > > *multiple adjoining whitespace characters are treated the same as an*
> > >* individual space*, and leading and trailing whitespace is ignored.
> > >
> > >
> > That was a good description of why this is the case.
> >
> > Alex
>
> At a point, we may want to have a DnParser, and a DnNormalizer. The
> DnParser will just check that the DN is correct, and the DnNormalizer
> will use the Schema to transform the NameComponents.
>
> It's not obvious that the normalization should occur during the parsing.
> I don't know if just a question of separation of concern, or of
> performance is improved by this three phases process (I don't think so),
> but the fact is that we should go through those three phases :
>
> 1) String -> nameComponents
> 2) nameComponents -> normalized nameComponents
> 3) normalized nameComponents -> normalized String
>
> What is the best solution?
>
> wdyt ?
>
> >
> > ---------------------------------------------------------------------------------------
> > Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> > Aucun virus connu a ce jour par nos services n'a ete detecte.
> >
> >
> >
>
>
>
>
--
Ersin
Re: DnParser
Posted by Emmanuel Lecharny <el...@apache.org>.
<snip/>
> >8.1 :
> >...
> >When performing the caseIgnoreMatch, caseIgnoreListMatch,
> > telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
> > *multiple adjoining whitespace characters are treated the same as an*
> >* individual space*, and leading and trailing whitespace is ignored.
> >
> >
> That was a good description of why this is the case.
>
> Alex
At a point, we may want to have a DnParser, and a DnNormalizer. The
DnParser will just check that the DN is correct, and the DnNormalizer
will use the Schema to transform the NameComponents.
It's not obvious that the normalization should occur during the parsing.
I don't know if just a question of separation of concern, or of
performance is improved by this three phases process (I don't think so),
but the fact is that we should go through those three phases :
1) String -> nameComponents
2) nameComponents -> normalized nameComponents
3) normalized nameComponents -> normalized String
What is the best solution?
wdyt ?
>
> ---------------------------------------------------------------------------------------
> Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
Re: DnParser
Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:
> On Tue, 2005-10-18 at 15:52 -0700, Gianmaria Clerici wrote:
>
>> NormalizationService will use org.apache.ldap.common.name.DnParser to
>> normalize a Name.
>>
>>
>>
>> For instance, if my Name looks like this:
>>
>> ou=Sub Production V,bsiViewName=Direct Report View
>>
>>
>>
>> It will return this:
>> ou=sub production v,bsiViewName=direct report view
>>
>>
>>
>> As you can see it will replace the 2 spaces before the V with one space.
>>
>>
>>
>> Is this the correct behavior ?
>
>
> Even if stange, this is plain normal. The reason is that 'ou' (OID
> *2.5.4.11*) inherits from attribute 'name' (OID *2.5.4.41) which
> syntax is :*
>
>
> name ATTRIBUTE ::= {
>
> WITH SYNTAX DirectoryString {MAX}
> EQUALITY MATCH RULE caseIgnoreMatch
> SUBSTRINGS MATCHING RULE caseignoreSubstringsMatch
> ID {id-at-name}
>}
>
>Its EQUALITY MATCH RULE is caseIgnore Match, and the RFC 2252 says :
>
>8.1 :
>...
>When performing the caseIgnoreMatch, caseIgnoreListMatch,
> telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
> *multiple adjoining whitespace characters are treated the same as an*
>* individual space*, and leading and trailing whitespace is ignored.
>
>
That was a good description of why this is the case.
Alex
Re: Which commons-collection do we use?
Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:
>Hi all,
>
>there are still two different libraries used in ApacheDS :
> - commons-collection 2.1
> - commons-collection 3.0
> - commons-collection 3.1
>
>Alex replaced the 3.1 version to a 3.0 in apache2-provider this morning,
>but it's not enough. Here is all the references we have :
>
>2.1 :
>-----
>client-ldap !!!
>snacc-provider ( it doesn't matter ...)
>
>3.0 :
>-----
>apacheds-main
>asn1-ber
>apache-provider
>apache2-provider
>
>
>3.1 :
>-----
>apacheds-core
>naming-config
>
>
>I guess that, from now on, 3.0 is the right version.
>
>
Oh man this is ugly :(.
Ok let's just move everything to 3.1 if nothing is deprecated. The ldap
client stuff is not critical either ... these changes should not take
that much if any at all to fix.
Thanks for pointing this out.
Alex
Which commons-collection do we use?
Posted by Emmanuel Lecharny <el...@apache.org>.
Hi all,
there are still two different libraries used in ApacheDS :
- commons-collection 2.1
- commons-collection 3.0
- commons-collection 3.1
Alex replaced the 3.1 version to a 3.0 in apache2-provider this morning,
but it's not enough. Here is all the references we have :
2.1 :
-----
client-ldap !!!
snacc-provider ( it doesn't matter ...)
3.0 :
-----
apacheds-main
asn1-ber
apache-provider
apache2-provider
3.1 :
-----
apacheds-core
naming-config
I guess that, from now on, 3.0 is the right version.
wdyt ?
-- Emmanuel
Re: DnParser
Posted by Emmanuel Lecharny <el...@apache.org>.
On Tue, 2005-10-18 at 15:52 -0700, Gianmaria Clerici wrote:
> NormalizationService will use org.apache.ldap.common.name.DnParser to
> normalize a Name.
>
>
>
> For instance, if my Name looks like this:
>
> ou=Sub Production V,bsiViewName=Direct Report View
>
>
>
> It will return this:
> ou=sub production v,bsiViewName=direct report view
>
>
>
> As you can see it will replace the 2 spaces before the V with one
> space.
>
>
>
> Is this the correct behavior ?
Even if stange, this is plain normal. The reason is that 'ou' (OID
2.5.4.11) inherits from attribute 'name' (OID 2.5.4.41) which syntax
is :
name ATTRIBUTE ::= {
WITH SYNTAX DirectoryString {MAX}
EQUALITY MATCH RULE caseIgnoreMatch
SUBSTRINGS MATCHING RULE caseignoreSubstringsMatch
ID {id-at-name}
}
Its EQUALITY MATCH RULE is caseIgnore Match, and the RFC 2252 says :
8.1 :
...
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored.
> I will need to look up an object using the normalized value (down in
> my partition code), but it’s a bit more challenging if the spaces have
> been, partially, removed.
Yes, it's challenging ;) And it's *not* funny at all to implement
either !
-- Emmanuel