Hi!
a quick update on my side.
o I'm currently trying to shoot as many issue as possible. Last week, I
have switched from using our Base64 implementation to the
java.util.Base64 class. It seems to have some impact on our code,
because our implementation was expecting all the Strings to be UTF-8
encoded. For the java.util.Base64 class, we really need to create a
String from the obtained bytes using a StandardCharsets.UTF_8 parameter.
There are a few places in the LDAP API and teh server where this is not
the case. I'm currently dealing with that issue.
o Another change is that I have now switched completely to Junit5. I was
thinking it was already the case - and I did the switch partially last
year - but it was not the case, I left a *lot* of tests using junit4.
The simple fact that I bumped up the maven surefire pluging from
3.0.0-M3 to 3.0.0-M5 made those tests failing. It took me a while to
understand why they were failing, and how to fix that. It's now done.
o I have changed the ExtendedRequest hierarchy to have all the
implementation inherit from OpaqueExtendedRequest, and made this class
storing the value byte[]. That has no impact oin the operations, but it
let those who don't mind dealing with the specific ExtOp the possibility
to cast the request to an OpaqueExtendedRequest, and call getValue() on
it to get back the byte[]. This is convenient.
o Last, not least, I found a bug in the way we process filters. In the
case where we have a filter like (ObjectClass=person*), the filter
should be ignored (ObjectClass does not have a Substring MatchingRule).
In this case, the entry that has an attribute which filter is undefined
should be ignored, which is niot currently the case.
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
[email protected] https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
