I've created it. It mixes ModificationItems and Entries, with a DN, so
we cover all the cases.
I can't commit the change (infra pb), but that's fine because I need
to fix the pb with the previous LdifReader.
btw, I'm not sure that allowing the server to injext a ldif file
whenstarting is such a good idea... Let me elaborate a lil bit : what
if your server is restarted? The ldif will be injected again. And that
may not be the expected behavior. wdyt ?
It could be better to have a tool to inject Ldif entries and changes
into the server (like LdifDe). IMHO :)
On 5/12/06, Alex Karasulu <[EMAIL PROTECTED]> wrote:
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
>>
>
>
--
Cordialement,
Emmanuel Lécharny
