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 Lécharny <el...@gmail.com> on 2018/07/09 12:54:21 UTC
LDAP 2.0 and beyond, was : Re: SCIMple, current state of Apache LDAP
2.0, and Java 9/10/11
<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.
But
> 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
etc...
>
>> 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 (http://jdk.java.net/11/) 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
Symas.com
directory.apache.org
Re: LDAP 2.0 and beyond, was : Re: SCIMple, current state of Apache
LDAP 2.0, and Java 9/10/11
Posted by Emmanuel Lécharny <el...@gmail.com>.
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
registry.
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
}
else
{
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
asap.
>
>> 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 (http://jdk.java.net/11/) 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
Symas.com
directory.apache.org
Re: LDAP 2.0 and beyond, was : Re: SCIMple, current state of Apache
LDAP 2.0, and Java 9/10/11
Posted by Radovan Semancik <ra...@evolveum.com>.
On 07/09/2018 02:54 PM, Emmanuel Lécharny wrote:
> 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).
Exactly. That's what I thought. And also won't work if you want to
connect to nice LDAP and naughty LDAP at the same time. Loggers are
essentially singletons. So unless someone invents quantum logger they
cannot be both on on off at the same time :-)
> 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.
We have to pay the price only if the listener is configured. Otherwise
we will just pay price of "if (listener != null) {}" check. Not a bad
price to pay for getting rid of complaints about AD schema errors.
> 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);
}
I have do dig deeper in the code to figure out how to hide this in some
superclass or util class, so we won't repeat the code everywhere. But I
think this could work. And in fact, it may even be a compatible API change.
> 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)
Oh yes. That may be the way. Good idea.
> 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.
> 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 :-)
> 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
> etc...
Oh good. I like faster versioning. Let's see how the change looks like
when I'm done. I'll keep it on a branch. It is not really critical do
get it in 2.0 if 3.0 will be released soon enough.
> Java 11 is going t be out in 2 months and a half. We already have some
> early-access versions (http://jdk.java.net/11/) 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.
--
Radovan Semancik
Software Architect
evolveum.com