directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radovan Semancik <>
Subject Re: isHumanReadable in LdapSyntax
Date Fri, 06 Mar 2015 06:50:01 GMT

Thanks for comments. I'll have a look at the  *Tags enums. But I guess 
it will be a bit inconvenient for me to work on my github fork and you 
working on svn trunk ...

I would suggest this: let me finish my rudimentary implementation. Now I 
have to speed things up a bit, so it probably won't take longer than a 
week or two. I'm using VLV and schema in my LDAP connector for midPoint. 
I'm also working on automated tests that will use 
midPoint+connector+directory API with OpenLDAP and 389ds (I already have 
tests for OpenDJ). Once I have that then I will create a pull request so 
it can get to the directory API project trunk. The code will probably be 
a bit ugly ... but once it is in trunk you are free to clean it up. And 
as I will have the tests I can check that it still works after your 
cleanup ...

I was thinking about how to make unit tests for this directly in the 
directory API project. Simple tests for VLV controls parse and encode 
will be probably a good idea. But this is not really enough to make sure 
that the whole thing really works. Do you have any kind of test suite 
for directory API that is using real LDAP servers?


                                            Radovan Semancik
                                           Software Architect

On 03/05/2015 07:08 PM, Emmanuel L├ęcharny wrote:
> We declare the tags in a XXXTags file, like in :
> public enum PasswordPolicyTags
> {
>      PPOLICY_WARNING_TAG(0xA0), // warning [0]
>      PPOLICY_ERROR_TAG(0x81), // error [1]
>      TIME_BEFORE_EXPIRATION_TAG(0x80), // timeBeforeExpiration [0]
>      GRACE_AUTHNS_REMAINING_TAG(0x81); // graceAuthNsRemaining [1]
>      ...
> One thing that is missing is the choice between byteOffset and an
> assertionValue : we should have a flag in the impl to determinate which
> of the two is in use.
> the contextID might be empty, and might be absent from the PDU. Those
> are 2 different use cases. We should cover both.
> The VLV control will probably be put into the codec-extras module.
> I'll check that tonite !

View raw message