directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject LDAP 2.0 and beyond, was : Re: SCIMple, current state of Apache LDAP 2.0, and Java 9/10/11
Date Mon, 09 Jul 2018 12:54:21 GMT
<changing the title for clarity>

Le 09/07/2018 à 13:46, Radovan Semancik a écrit :
> Hi,
> On 07/01/2018 09:40 AM, Emmanuel Lécharny wrote:
>> Otherwise, the APache LDAP API 2.0 is on its way, I have fixed a long
>> lasting ticket about reshuffling the error/messages numbering - quite a
>> pain in the back...- and I still have a pending issue in ApacheDS with
>> this revision : one failing test, related to using teh
>> DelegatingAuthenticator, when using startTLS. It's complicated, because
>> it involves a client (the LDAP API), a server, which talks to another
>> server using the LDAP API, and MINA. Of course to muddy the thing, there
>> are connection timeout issues - a bug I fixed and I still have to
>> commit -.
> I'm planning to change the way how schema errors are handled in API 2.0
> devel cycle. The problem is that there are popular LDAP servers with
> really bad schema (e.g. AD).

How surprising !!!

 And in that case the LDAP API floods the
> logfiles with warnings. I would like to make this behavior configurable,
> provide "listener" for errors or do something like that.

That seems reasonnable.

I guess most of the errors are produced by the
DefaultSchemaObjectRegistry class.

If so, I wonder if a more simple solution would'nt be to create a
specific Logger for such a thing as AD, and configure the property file
to mute the other loggers. OTOH, that would require to either tune the
property file *before* connecting to an AD server (and that means we
*know* we are talking to such a turd), or that we programatically
configure the logger (which might not be easy considering we use a
facade like slf4j).

Now, using a listener solve both drawbacks, we just have to pay the
price of an indirection (ok, I assume it's not a terrible big deal), and
to have a way to configure this listener.

One last solution : pass a flag (like 'MUTE_WARNINGS') to the API while
processing a schema, and have something like :

            if ( LOG.isWarnEnabled() && !muteWarnings )
                LOG.warn( msg );

We would initiate the flag when instanciating the registries:

    public Registries( boolean muteWarnings )
        globalOidRegistry = new OidRegistry<>();
        attributeTypeRegistry = new DefaultAttributeTypeRegistry(
muteWarnings );
        comparatorRegistry = new DefaultComparatorRegistry( muteWarnings );

Whatever works, just suggesting an alternative idea, not pretending it's
better, but offering options.

> implementing that properly is likely to introduce non-compatible changes
> to SchemaManager and surrounding classes.

The XXXRegistry classes are not to be used from external callers. The
Registries class can be extended, by adding a parameter, and the
constructor with no parameter will simply works as designed initally.
This would change the API ina  very minimal way (being compatible with
teh current version)

 I think I have proposed this
> change some time ago and we have decided to wait for 2.0. So now I would
> like to implement it. Emmanuel, please let me know whether it is right
> time to do it now. I would not like to clash with your changes.

2.0.0-AM1 is pretty much done. I intend to cut a release this week, so I
guess it's a bit late to introduce such a change, except if you think
you can cut it very quickly. To be franck, I've a lot to do on my day
job atm, and the baby is draining the remaining energy I have, so I was
planning to cut this release this week-end, so that leave you some room
for such a change. We just have to be sure that does not break the
server, but I don't think I can't fix any breakage there in more than a
couple of hours. Same for studio.

Bottom line, this is not such a big change, if properly handled - and I
trust your skill here :-) -

If you come to realize it's going to be a bigger breakage than what I
think, then I'd rather call for a 3.0. IMO, 2.0 is almost dne, and I'm
willing to move to a faster numbering release, à la Chrome/Firefox. Ie,
instead of cutting some 2.0.1, 2.1.0 etc, I'd ratcher go for 3.0/4.0/5.0

>> Last, not least, it's probably time to try to have all thos projects
>> working fine with the latest Java version (and specificlly with Java 11
>> which will be the LTS version). We have more and more people
>> complainging about issues with those versions, but I o think it's not an
>> enormous tasks we have in front of us.
> I would test API with Java 11, once Java 11 is released.

Java 11 is going t be out in 2 months and a half. We already have some
early-access versions ( and I know that The ASF
has already configured Jenkins to support Java 11.

I would say : the faster, the better, but of course, this is depending
on teh will of volunters... And we are not many :-)

Ideally speaking, I'd like to have the API ready before Java 11 is out.
Not sure we will be heavilly impacted. Anyway, I'm going to give it a
try in agust.

 But as for Java
> 9 and 10 we are ignoring them completely.

Java 9/10? What is that ?

 Therefore I won't be able to
> help with those.

Me neither ;-)

Many thanks, Radovan !

Emmanuel Lecharny

View raw message