Emmanuel Lecharny wrote:
ok. So if the 'new' Ldif reader does not add this DN in the
BasicAttributes, I guess that is the normal behavior. Now, about the
previous code, this is a part of a test which load entries provided by
the 'old' ldif reader, and I guess that it's the only way to get the
DN.
In this case, yes, this code makes perfect sense.
Thanks Alex !
Np sorry about the confusion Emmanuel. I guess we should have a special
data structure for things read from an LDIF since it is not going to be
an attribute always.
Alex
On 5/12/06, Alex Karasulu <[EMAIL PROTECTED]> wrote:
Emmanuel Lecharny wrote:
> Hi all,
>
> I'm trying to figure out if code like :
>
> ...
> Attributes entry = ( Attributes ) i.next();
> if ( entry.get( "dn" ) == null )
> {
> throw new ConfigurationException( "Test entries must
> have DN attributes" );
> }
> ...
>
> makes sense or not.
>
> In my mind, Attributes should not containes "dn", because "dn" is
> already stored elswhere. Am I wrong ? wdyt ?
Depends on what created the "entry". The old LDIF parser will return
the dn as an attribute which needs to be removed. This is the ONLY
Place where DN is an attribute in the entry.
Alex
