directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Back from vacations, working on Value/Ava/Rdn/Dn
Date Wed, 04 May 2016 22:30:46 GMT
Hi guys,

sadly, I'm back... I wish I could still be in Greece, enjoying the
spelndid weather.

Anyway, last week-end, I was able to continue what I was working on :
revamping the Value/Ava/Rdn/Dn classes, to make them immutable and to
correctly deal with the various pb we had.

One thing I realized while being far from my computer is that since day
one (so 10 years ago), we have made a mistake : focusing on DN as if it
was a String that needed to be converted to a data structure, instead of
doing the opposite thing : it's a data structure that need to be
converted to a String. It sounds silly, but it makes a hell lit of
difference. The main thing is that the Value should always be a byte[]
representing what the user put into it. Having a normalized form that is
exposed for it is a non-sense. Actually, the normalized form is only
useful when doing comparisons. This is the exact same thing for Ava, Rdn
and Dn.

At the end of the day, we just need to normalize on the fly, when we
need to compare the value. That also mean we won't be able anymore to do
things like :

dn.getNormValue() );

but instead, we should do :

    dn.equals( "uid=admin,ou=system" );

or even better :

    dn.equals( ADMIN_DN );

assuming the ADMIN_DN value is a static Dn.

When we need to use a Dn or a value in a Filter, we now need to call
Dn/Rdn/Ava/Value.getEscaped() which returns the properly String
representation of the element, with all the escaped chars that are

Otherwise, making the various classes immutable simplify the work and
the API.

Atm, I've been able to rework the Value, Ava and Rdn classes, and the
associated tests. I still have to make the Rdn class immutable (removing
the apply(SchemaManager) method from it), and then the DN class. The
next step will be to fix the API to use the simplified API.

It's a bit of work, and I'll have to wait for the week-end to proceed,
but I feel it's going to make it easier and more consistent in the long

Last, not least, I have also greatly simplified the ComplexDnParser
grammar. Antlr is not very cool when it comes to handle conflict... But
anyway, I have it working now.

More to come !

View raw message