On 08/10/2015 12:42 PM, Emmanuel Lécharny wrote:
There is no flag that says an Attribute is H-R or not. The information
is provided in RFC 22524.3.2
<https://tools.ietf.org/html/rfc2252#section-4.3.2>
Hmm, I was code for parsing of "X-NOT-HUMAN-READABLE" so I thought that
it might be caused by this. Thanks for clarification. Anyway, the
strange thing is that the syntax 1.3.6.1.4.1.1466.115.121.1.28 appears
to be human readable.
But then jpegPhoto is obviously binary. When I try to modify it with
BinaryValue it ends up with:
ERROR (o.a.d.api.ldap.model.entry.DefaultAttribute): ERR_04451 The
value must be a String, as its AttributeType is H/R
I'm doing the equivalent of attribute.add(new BinaryValue(bytes));
Hmmm... Do you have the full code as a test I can run on my machine ?
Try this:
LdapNetworkConnection conn = new
LdapNetworkConnection("localhost", 10389);
DefaultSchemaLoader schemaLoader;
schemaLoader = new DefaultSchemaLoader(conn, true);
DefaultSchemaManager schemaManager = new
DefaultSchemaManager(schemaLoader);
schemaManager.setRelaxed();
schemaManager.loadAllEnabledRelaxed();
AttributeType jpegPhotoAttributeType =
schemaManager.getAttributeType("jpegPhoto");
System.out.println("jpegPhoto AttributeType =
"+jpegPhotoAttributeType);
LdapSyntax syntax = jpegPhotoAttributeType.getSyntax();
System.out.println("jpegPhoto syntax = "+syntax);
System.out.println("jpegPhoto syntax H/R =
"+syntax.isHumanReadable());
But there is a very strange thing going on. Trying it with OpenDJ (2.6)
I got this:
jpegPhoto AttributeType = attributetype ( 0.9.2342.19200300.100.1.60
NAME 'jpegPhoto'
DESC 'a JPEG image'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.28
USAGE userApplications )
jpegPhoto syntax = ldapsyntax ( 1.3.6.1.4.1.1466.115.121.1.28
DESC 'JPEG'
X-NOT-HUMAN-READABLE 'false' )
jpegPhoto syntax H/R = true
But running it with OpenLDAP (2.4.31) I got this:
jpegPhoto AttributeType = attributetype ( 0.9.2342.19200300.100.1.60
NAME 'jpegPhoto'
DESC 'RFC2798: a JPEG image'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.28
USAGE userApplications )
jpegPhoto syntax = ldapsyntax ( 1.3.6.1.4.1.1466.115.121.1.28
DESC 'JPEG'
X-NOT-HUMAN-READABLE 'true' )
jpegPhoto syntax H/R = false
The attribute schema definition is almost identical:
OpenDJ
attributeTypes: ( 0.9.2342.19200300.100.1.60 NAME 'jpegPhoto' DESC 'a
JPEG ima
ge' SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 X-ORIGIN 'RFC 2798' )
OpenLDAP
attributeTypes: ( 0.9.2342.19200300.100.1.60 NAME 'jpegPhoto' DESC
'RFC2798: a
JPEG image' SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )
Could the X-ORIGIN make a difference here?
And one related remark. The add( Value<?>... vals ) method in
DefaultAttribute is not very convenient to use and still keep a good
error reporting. E.g. in the above case it will not throw any error,
just returns zero. This is enough to detect that there was an error
(not very convenient though). But the reason why the attribute cannot
be added is lost. I cannot report back to the higher layers anything
better than "failed to add foo to bar". But the user will not know
what was the reason.
Yes, that's true. the rational is that we do a best effort to inject
values correctly, converting them on the fly.
Note that this H-R flag itself is stupid. It was added 12 years ago as a
way to follow teh RFC, but as a matter of fact, the Syntax itself
already drives the type of data we can store in an Attribute. I made it
even more complex by trying to use Generics. Now, we have those
StringValue and BinaryValue all over the code.
Ideally, we should not have to care about what we store, and always
consider the stored values as byte[]. OTOH, it's not convenient when we
want to manipulate values as String, as converting them over and over
from byte[] to Strings is costly (epecially in the server). But I do
think we went way to far here. This conversion should be done internally
once, and that's it. It would save us a hell lot of time, and would make
the APi more comfortable to use.
I tend to agree. Always storing the value as binary seems to be good idea.
I'm working on a similar problem with Novell/NetIQ eDirectory. eDir has
a binary GUID. But the API seems to try to interpret it as String. As it
contains some invalid UTF codes it completely breaks the value and there
is no way how to fix this on the API client side. Storing the value as
binary will solve this kind of issues. This specific eDir GUID problem
is probably my fault as the Studio seems to work with the GUID without
any problems. I'll report on that later when I investigate it. Anyway,
the API is currently not very intuitive with the BinaryValue,
StringValue and H/R flags. Simplification will be a great help for new
API users.
--
Radovan Semancik
Software Architect
evolveum.com
