<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
pEpkey.asc
Description: application/pgp-keys
