directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: 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 14:28:09 GMT

Le 09/07/2018 à 15:28, Radovan Semancik a écrit :

>> 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.
> I think the flag is redundant. Setting a listener to non-null value will
> do the same trick:
> if (errorListener == null) {
>     LOG.warn( msg );
> } else {
>     errorListener.accept(msg);
> }

Which is not different from

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

You have to define the errorListener somwhere, as you have to set the
muteWarnings. This can be done at teh same place, propagated to the

The difference is that the muteRegistry is really limited in
functionality, while the listener *may* handle more things (like, you
may define a ADListener that will keep some warnings, but that would be
a bit complex to handle, as you must have some knowledge about the
warnings you want to keep).

All in all, you can't really decouple the warning you want to produce
from the pace in the code it's produced, so that could lead to things like :

    String msg = I18n.err( I18n.ERR_13733_ARG_NOT_NUMERIC_OID );

    if ( listener instanceof ADListener )
        LOG.trace( msg ); // We don't want to be flooded with logs in AD
    else if ( listener instanceof OPENLDAPListener
        LOG.error( msg );  // OpenLDAP is stricter
        LOG.warn( msg ); // Default mode

and that for each specific message...

Unless you want to be global, and make the listener globally push AD
logs to TRACE (and eventually get them ignored because the default log
level is INFO, which means your approach works.

>> 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.
> I'm not sure either. But I'll try on Wednesday or Thursday. If I can't
> make it I just won't merge the changes to master and it won't be in AM1.
> It looks like we can make this change compatible with previous API, so
> probably no problem there

Sure, please do your experiments in a branch, so that I can play with it

>> Bottom line, this is not such a big change, if properly handled - and I
>> trust your skill here :-) -
> Thank you. I'll try to to live up to expectations :-)

I always set my expectations as high as my level of competence. Which is
fine for 90% of the developpers on this planet. I'm pretty sure you can
pass this bar easily ;-)

>> 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 think I'll be a bit conservative here and wait for Java 11 release. I
> know that Oracle has made promises. But please forgive me if I'm not
> entirely ready to believe :-)
> I'm quite happy with Java 8 for API 2.0.

Me too. Many others too. And Oracle new policy (ie, let the Java users
dead in the water very fast, forcing them to either pay the Oracle taxe
- and it's a freaking heavy one !!! -, or switch to a newest version
every year, is pretty likely to kill Java in the coming years. Unless
you are ready to keep going with OpenJDK.

That makes me think we should start basing our developments and tests on
OpenJDK rather on an Oracle JDK... But that is another discussion to have !

Emmanuel Lecharny

View raw message