Apache Directory Project - Attributes and DN question

Author

Attributes and DN question

Emmanuel Lecharny

2006-05-12, 1:11 am

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.

Alex Karasulu

2006-05-12, 1:11 pm

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

Emmanuel Lecharny

2006-05-12, 1:11 pm

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 <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org> wrote:
> Emmanuel Lecharny wrote:
>
> 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
>

--=20
Cordialement,
Emmanuel L=E9charny

Alex Karasulu

2006-05-12, 1:11 pm

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 <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org> wrote:
>
>

Emmanuel Lecharny

2006-05-12, 1:11 pm

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 <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org> wrote:
> Emmanuel Lecharny wrote:
>
> 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
>
>
>

--=20
Cordialement,
Emmanuel L=E9charny

Ersin Er

2006-05-12, 7:11 pm

TERJRiBpbXBvcnRlZCBtYXkgYmUgaW52b2tlZCB2
aWEgYW4gZXh0ZW5kZWQgb3BlcmF0aW9uLiBU
aGUgc2luZ2xlCnBhcmFtZXRlciBvZiB0aGUgb3Bl
cmF0aW9uIG1heSBiZSBhbiBMRElGIGZpbGUg
Y29udGVudC4KCkJUVywgbm90IGRpcmVjdGx5IHJl
bGF0ZWQgYnV0IHlvdSBtYXkgaGF2ZSBhIGxv
b2sgYXQgdGhpczoKCmh0dHA6Ly9yZmM0MzczLng0
Mi5jb20vCgpDaGVlcnMsCgpPbiA1LzEyLzA2
LCBFbW1hbnVlbCBMZWNoYXJueSA8ZWxlY2hhcm55
QGdtYWlsLmNvbT4gd3JvdGU6Cj4gSSd2ZSBj
cmVhdGVkIGl0LiBJdCBtaXhlcyBNb2RpZmljYXRp
b25JdGVtcyBhbmQgRW50cmllcywgd2l0aCBh
IEROLCBzbwo+IHdlIGNvdmVyIGFsbCB0aGUgY2Fz
ZXMuCj4KPiBJIGNhbid0IGNvbW1pdCB0aGUg
Y2hhbmdlIChpbmZyYSBwYiksIGJ1dCB0aGF0J3Mg
ZmluZSBiZWNhdXNlIEkgbmVlZAo+IHRvIGZp
eCB0aGUgcGIgd2l0aCB0aGUgcHJldmlvdXMgTGRp
ZlJlYWRlci4KPgo+IGJ0dywgSSdtIG5vdCBz
dXJlIHRoYXQgYWxsb3dpbmcgdGhlIHNlcnZlciB0
byBpbmpleHQgYSBsZGlmIGZpbGUKPiB3aGVu
c3RhcnRpbmcgaXMgc3VjaCBhIGdvb2QgaWRlYS4u
LiBMZXQgbWUgZWxhYm9yYXRlIGEgbGlsIGJp
dCA6IHdoYXQKPiBpZiB5b3VyIHNlcnZlciBpcyBy
ZXN0YXJ0ZWQ/IFRoZSBsZGlmIHdpbGwgYmUg
aW5qZWN0ZWQgYWdhaW4uIEFuZCB0aGF0Cj4gbWF5
IG5vdCBiZSB0aGUgZXhwZWN0ZWQgYmVoYXZp
b3IuIHdkeXQgPwo+Cj4gSXQgY291bGQgYmUgYmV0
dGVyIHRvIGhhdmUgYSB0b29sIHRvIGluamVj
dCBMZGlmIGVudHJpZXMgYW5kIGNoYW5nZXMKPiBp
bnRvIHRoZSBzZXJ2ZXIgKGxpa2UgTGRpZkRl
KS4gSU1ITyA6KQo+Cj4gT24gNS8xMi8wNiwgQWxl
eCBLYXJhc3VsdSA8YW9rMTIzQGJlbGxzb3V0
aC5uZXQ+IHdyb3RlOgo+ID4gRW1tYW51ZWwgTGVj
aGFybnkgd3JvdGU6Cj4gPiA+IG9rLiBTbyBp
ZiB0aGUgJ25ldycgTGRpZiByZWFkZXIgZG9lcyBu
b3QgYWRkIHRoaXMgRE4gaW4gdGhlCj4gPiA+
IEJhc2ljQXR0cmlidXRlcywgSSBndWVzcyB0aGF0
IGlzIHRoZSBub3JtYWwgYmVoYXZpb3IuIE5v
dywgYWJvdXQgdGhlCj4gPiA+IHByZXZpb3VzIGNv
ZGUsIHRoaXMgaXMgYSBwYXJ0IG9mIGEgdGVz
dCB3aGljaCBsb2FkIGVudHJpZXMgcHJvdmlkZWQg
YnkKPiA+ID4gdGhlICdvbGQnIGxkaWYgcmVh
ZGVyLCBhbmQgSSBndWVzcyB0aGF0IGl0J3MgdGhl
IG9ubHkgd2F5IHRvIGdldCB0aGUKPiA+ID4g
RE4uCj4gPiA+Cj4gPiA+IEluIHRoaXMgY2FzZSwg
eWVzLCB0aGlzIGNvZGUgbWFrZXMgcGVyZmVj
dCBzZW5zZS4KPiA+ID4KPiA+ID4gVGhhbmtzIEFs
ZXggIQo+ID4KPiA+IE5wIHNvcnJ5IGFib3V0
IHRoZSBjb25mdXNpb24gRW1tYW51ZWwuICBJIGd1
ZXNzIHdlIHNob3VsZCBoYXZlIGEgc3BlY2lh
bAo+ID4gZGF0YSBzdHJ1Y3R1cmUgZm9yIHRoaW5n
cyByZWFkIGZyb20gYW4gTERJRiBzaW5jZSBp
dCBpcyBub3QgZ29pbmcgdG8gYmUKPiA+IGFuIGF0
dHJpYnV0ZSBhbHdheXMuCj4gPgo+ID4gQWxl
eAo+ID4KPiA+ID4KPiA+ID4gT24gNS8xMi8wNiwg
QWxleCBLYXJhc3VsdSA8YW9rMTIzQGJlbGxz
b3V0aC5uZXQ+IHdyb3RlOgo+ID4gPj4gRW1tYW51
ZWwgTGVjaGFybnkgd3JvdGU6Cj4gPiA+PiA+
IEhpIGFsbCwKPiA+ID4+ID4KPiA+ID4+ID4gSSdt
IHRyeWluZyB0byBmaWd1cmUgb3V0IGlmIGNv
ZGUgbGlrZSA6Cj4gPiA+PiA+Cj4gPiA+PiA+IC4u
Lgo+ID4gPj4gPiAgICAgICAgICAgIEF0dHJp
YnV0ZXMgZW50cnkgPSAoIEF0dHJpYnV0ZXMgKSBp
Lm5leHQoKTsKPiA+ID4+ID4gICAgICAgICAg
ICBpZiAoIGVudHJ5LmdldCggImRuIiApID09IG51
bGwgKQo+ID4gPj4gPiAgICAgICAgICAgIHsK
PiA+ID4+ID4gICAgICAgICAgICAgICAgdGhyb3cg
bmV3IENvbmZpZ3VyYXRpb25FeGNlcHRpb24o
ICJUZXN0IGVudHJpZXMgbXVzdAo+ID4gPj4gPiBo
YXZlIEROIGF0dHJpYnV0ZXMiICk7Cj4gPiA+
PiA+ICAgICAgICAgICAgfQo+ID4gPj4gPiAuLi4K
PiA+ID4+ID4KPiA+ID4+ID4gbWFrZXMgc2Vu
c2Ugb3Igbm90Lgo+ID4gPj4gPgo+ID4gPj4gPiBJ
biBteSBtaW5kLCBBdHRyaWJ1dGVzIHNob3Vs
ZCBub3QgY29udGFpbmVzICJkbiIsIGJlY2F1c2Ug
ImRuIiBpcwo+ID4gPj4gPiBhbHJlYWR5IHN0
b3JlZCBlbHN3aGVyZS4gQW0gSSB3cm9uZyA/ IHdkeXQgPwo+ID4gPj4KPiA+ID4+IERlcGVuZHMg

b24gd2hhdCBjcmVhdGVkIHRoZSAiZW50cnkiLiAg
VGhlIG9sZCBMRElGIHBhcnNlciB3aWxsIHJl
dHVybgo+ID4gPj4gdGhlIGRuIGFzIGFuIGF0dHJp
YnV0ZSB3aGljaCBuZWVkcyB0byBiZSByZW1v
dmVkLiAgVGhpcyBpcyB0aGUgT05MWQo+ID4gPj4g
UGxhY2Ugd2hlcmUgRE4gaXMgYW4gYXR0cmli
dXRlIGluIHRoZSBlbnRyeS4KPiA+ID4+Cj4gPiA+
PiBBbGV4Cj4gPiA+Pgo+ID4gPgo+ID4gPgo+
ID4KPiA+Cj4KPgo+IC0tCj4gQ29yZGlhbGVtZW50
LAo+IEVtbWFudWVsIEzDqWNoYXJueQo+CgoK
LS0gCkVyc2luCg==

Alex Karasulu

2006-05-13, 1:11 am

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 <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org> wrote:
>
>

Emmanuel Lecharny

2006-05-13, 7:11 am

Thanks Alex for the comments.

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

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

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

Alex Karasulu

2006-05-13, 1:11 pm

Emmanuel Lecharny wrote:
> Thanks Alex for the comments.
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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