You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2006/05/12 01:19:35 UTC
Attributes and DN question
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 ?
Emmanuel.
Re: Attributes and DN question
Posted by Ersin Er <er...@gmail.com>.
LDIF imported may be invoked via an extended operation. The single
parameter of the operation may be an LDIF file content.
BTW, not directly related but you may have a look at this:
http://rfc4373.x42.com/
Cheers,
On 5/12/06, Emmanuel Lecharny <el...@gmail.com> wrote:
> 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 <ao...@bellsouth.net> 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 <ao...@bellsouth.net> 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
>
--
Ersin
JavaOne Sessions (was Re: Attributes and DN question (2))
Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:
>
>>> Another point, Alex, if you have any pointer on Jeff's source (ldif
>>> import/export tools) it would be very helpfull !
>>>
>> Man I have not looked at this code in over two years. I'd have to
>> read through it again. Will see if I can do that during JavaOne.
>
> Don't loose your time... I've found the perfect place to put the code
> : into apacheds-tools. Importing ldif files is to be considered as an
> admin task, so I think it deserves a new command. I'm currently doing
> so, merging the old Add/Mod/Delete/Moddn command in Clients to do the
> trick.
>
> Hope you are J1-ready !!!
Yeah getting there. Thanks!!
BTW there will be a couple sessions that are not directly on ApacheDS
but talk about it at length. One of them is my presentation here:
https://www28.cplan.com/javaone06_cv_124_1/session_details.jsp?isid=277862&ilocation_id=124-1&ilanguage=english
Another is a BOF session on OSGi where Felix will be demonstrated
running ApacheDS as the first serious server side OSGi application
thanks to Enrique and Richard Hall.
If any of you guys will be at JavaOne I hope you see you guys there.
Cheers,
Alex
Re: Attributes and DN question (2)
Posted by Emmanuel Lecharny <el...@gmail.com>.
>> Another point, Alex, if you have any pointer on Jeff's source (ldif
>> import/export tools) it would be very helpfull !
>>
> Man I have not looked at this code in over two years. I'd have to
> read through it again. Will see if I can do that during JavaOne.
Don't loose your time... I've found the perfect place to put the code :
into apacheds-tools. Importing ldif files is to be considered as an
admin task, so I think it deserves a new command. I'm currently doing
so, merging the old Add/Mod/Delete/Moddn command in Clients to do the trick.
Hope you are J1-ready !!!
Emmanuel
Re: Attributes and DN question (2)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:
> Note that the newer version of LdifReader handle options after
> attributeType as part of the attribteType : 'givenname;lang-ja' and
> 'givenname' are considered as two attibuteType, not one.
Ahhh ok.
>
> Another point, Alex, if you have any pointer on Jeff's source (ldif
> import/export tools) it would be very helpfull !
>
Man I have not looked at this code in over two years. I'd have to read
through it again. Will see if I can do that during JavaOne.
Laters,
Alex
Re: Attributes and DN question (2)
Posted by Emmanuel Lecharny <el...@gmail.com>.
Note that the newer version of LdifReader handle options after
attributeType as part of the attribteType : 'givenname;lang-ja' and
'givenname' are considered as two attibuteType, not one.
Another point, Alex, if you have any pointer on Jeff's source (ldif
import/export tools) it would be very helpfull !
Thanks !
Re: Attributes and DN question
Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:
> Thanks Alex for the comments.
>
>>> 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?
>
> You bet I did ! I used them too, because they where there. It's
> difficult to reinvent the wheel on such a matter, because RFC 2849 is
> so restrictive that it does not leave you with many room to show how
> smart you can be !!! However, the actual implementation has some
> problems :
> - DIRSERVER 604 ( support of :< file://...)
> - DIRSERVER 618 ( support of changetype attribute )
> - DIRSERVER-187 ( multi-lines not accepted ) (Was DIRSERVER-199)
> - Added Control handling
> - There is a bad bug in value handling : "cn:valid name" is
> transformed to cn -> 'alid name' (the 'v' is deleted)
Heh this is good enough reason if you ask me to start from scratch :).
Lot's of problems thanks for addressing them Emmanuel.
>
>
> So I just considered reuse a LdifReader I wrote last year, before I
> knew about ADS (and it was the reason I lookad at ADS : I wanted to
> know if the Ldif Reader implementation was better than mine, and at
> this point, I was totally fascinated by the work done on ADS, so I
> stopped working on ldif). It was a piece of software I ported from a
> previous C# implementation I did too.
>
> I don't know, at this point, if it can be called a NIH syndrom ? May
> be a little bit, because I didn't had the feeling to fix the existing
> code while mine was almost working, so I decided to merge both,
> resuing ( with small modification) LdifEntry (renamed to Entry to
> avoid code breakage)
No this my bad. I did not know just how bad a state the current LDIF
reading code was. Again thanks for tackling these issues.
>
>
>>
>>> 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.
>
> Ok, cool ! I wasn't aware of that. Makes it totally sane, then. At
> least, for embeded servers, it's a much better solution than to force
> the user to import some data using an API. Forget about my objection.
You do have a good point about this potentially being an issue. I think
we should consider it again. I just don't have much juice right now to
put much thought into it.
>
>
>>>
>>> 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.
>
> I gonna check that. I guess it's in sandbox, so I will ressucicate it.
It's actually in the main trunk and in the 1.0 branch. It's got the
client code to do a graceful shutdown and things like that. It's the
tools module in apacheds/tools.
HTH,
Alex
Re: Attributes and DN question
Posted by Emmanuel Lecharny <el...@gmail.com>.
Thanks Alex for the comments.
>> 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?
You bet I did ! I used them too, because they where there. It's
difficult to reinvent the wheel on such a matter, because RFC 2849 is so
restrictive that it does not leave you with many room to show how smart
you can be !!! However, the actual implementation has some problems :
- DIRSERVER 604 ( support of :< file://...)
- DIRSERVER 618 ( support of changetype attribute )
- DIRSERVER-187 ( multi-lines not accepted ) (Was DIRSERVER-199)
- Added Control handling
- There is a bad bug in value handling : "cn:valid name" is transformed
to cn -> 'alid name' (the 'v' is deleted)
So I just considered reuse a LdifReader I wrote last year, before I knew
about ADS (and it was the reason I lookad at ADS : I wanted to know if
the Ldif Reader implementation was better than mine, and at this point,
I was totally fascinated by the work done on ADS, so I stopped working
on ldif). It was a piece of software I ported from a previous C#
implementation I did too.
I don't know, at this point, if it can be called a NIH syndrom ? May be
a little bit, because I didn't had the feeling to fix the existing code
while mine was almost working, so I decided to merge both, resuing (
with small modification) LdifEntry (renamed to Entry to avoid code breakage)
>
>> 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.
Ok, cool ! I wasn't aware of that. Makes it totally sane, then. At
least, for embeded servers, it's a much better solution than to force
the user to import some data using an API. Forget about my objection.
>>
>> 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.
I gonna check that. I guess it's in sandbox, so I will ressucicate it.
Thanks Alex !
Re: Attributes and DN question
Posted by Alex Karasulu <ao...@bellsouth.net>.
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 <ao...@bellsouth.net> 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 <ao...@bellsouth.net> 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
>> >>
>> >
>> >
>>
>>
>
>
Re: Attributes and DN question
Posted by Emmanuel Lecharny <el...@gmail.com>.
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 <ao...@bellsouth.net> 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 <ao...@bellsouth.net> 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
Re: Attributes and DN question
Posted by Alex Karasulu <ao...@bellsouth.net>.
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 <ao...@bellsouth.net> 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
>>
>
>
Re: Attributes and DN question
Posted by Emmanuel Lecharny <el...@gmail.com>.
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 !
On 5/12/06, Alex Karasulu <ao...@bellsouth.net> 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
Re: Attributes and DN question
Posted by Alex Karasulu <ao...@bellsouth.net>.
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