Emmanuel Lecharny wrote:
I've created it. It mixes ModificationItems and Entries, with a DN, so
we cover all the cases.
Did you have a look at the existing LDIF classes in shared-ldap ? Were they inadequate .. I know some features were not there. Also years ago Jeff Machols had worked on some LDIF code in the clients libraries. Unless there is some extra ordinary reason we should not reinvent the wheel?

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 ?
The server puts an entry into the ou=system area about the ldifs it loaded. It remembers what it has loaded. This is not the greatest thing in the world but it was a great way to get apps built on top of apacheds to load an initial LDIF file.

It could be better to have a tool to inject Ldif entries and changes
into the server (like LdifDe). IMHO :)
Well there is the apacheds-tools module. I intended to put this functionality there as well as some command line clients.

WDYT?

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
>>
>
>





Reply via email to