[
https://issues.apache.org/jira/browse/DIRSTUDIO-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16224214#comment-16224214
]
Emmanuel Lecharny commented on DIRSTUDIO-1160:
----------------------------------------------
Ok, I have gone to the bottom of the problem.
When we import a LDIF file, we use a parser that inject what we read in a JNDI
{{BasicAttributes}}. If the value is base 64 encoded, it's transformed to a
{{byte[]}} - at this point, we are not schema aware, so we can't know if this
{{byte[]}} is for a String or a binary value -.
Later on, we convert the JNDI {{BasicAttributes}} to an Apache LDAP API
{{entry}}, and in the current version of the API, if we have a {{byte[]}} for
the value, and if the attribute is {{HR}} - ie Human Readable, like
{{description}} is, this is a RFC 2252 definition, check on the 4.3.2 table -,
then the value is ignored :
{code:java}
public int add( byte[]... vals ) throws LdapInvalidAttributeValueException
{
...
if ( !isHR )
{
...
}
else
{
// We can't add Binary values into a String Attribute
LOG.info( I18n.err( I18n.ERR_04451 ) );
return 0;
}
{code}
So we must convert the {{byte[]}} to a String when we know that the attribute
is H/R before calling the LDAP API. The problem here is that we don't have any
idea if the attribute is H-R or not, and the flag is set when we inject the
very first value (which is a String).
If I move the 'binary' {{description}} value to be the first value, the sent
request is :
{code}
MessageType : ADD_REQUEST
Message ID : 23
Add Request :
Entry
dn: cn=U0034692,dc=symas,dc=com
objectClass: inetOrgPerson
uid: MyTestUser
givenName: 0x4A 0xC3 0xB6 0x68 0x6E 0x20 0x44 0x6F 0xC3 0xA4 0x65 0xC3 0xB6
displayName: 0x4A 0xC3 0xB6 0x68 0x6E 0x20 0x44 0x6F 0xC3 0xA4 0x65 0xC3
0xB6
description: 0x54 0x68 0xC3 0xB6 0x69 0x73 0x20 0xC3 0xA5 0x73 0x20 0x61
0x20 0x74 0xC3 0xA4 ...
description: 0x61 0x63 0x63 0x6F 0x75 0x6E 0x74 0x23 0x6F 0x6C 0x64 0x55
0x73 0x65 0x72 0x49 ...
description: 0x70 0x65 0x72 0x73 0x6F 0x6E 0x23 0x68 0x6F 0x6D 0x65 0x45
0x6D 0x61 0x69 0x6C ...
description: 0x49 0x6E 0x69 0x74 0x69 0x61 0x6C 0x20 0x69 0x6D 0x70 0x6F
0x72 0x74
description: 0x47 0x6F 0x6F 0x64 0x23 0x53 0x74 0x75 0x66 0x66
sn: Doe
{code}
with 5 values for the {{description}} attribute, and this time, I can see all
of them when I do a search.
I don't see easy solution to this problem. We could change the way the API
works, and stop making it decide that the Attribute is H/R or not depending on
the first value it contains, but that has a huge impact. One better solution
would be to always store the value as a {{byte[]}} and defer the conversion to
a String until we know we have to expose the value. This is not the choice that
has been made.
Another solution would be to stop using JNDI completely in Studio, and instead
use the schema aware API with the default schema loaded. That would work fine
for standard schema, not for unknown attributes :/
IMHO, the issue is in the API, and this is where it has to be solved, but this
is clearly not simple.
In the mean time, I would suggest to keep going with the JNDI connection, which
is working.
> Attributes silently dropped and not imported when import LDIF and provider is
> Apache Directory LDAP API
> -------------------------------------------------------------------------------------------------------
>
> Key: DIRSTUDIO-1160
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1160
> Project: Directory Studio
> Issue Type: Bug
> Affects Versions: 2.0.0-M13
> Environment: Windows 10 Creators Update
> Reporter: Aleks M
> Attachments: desc.ldif
>
>
> When importing the attached LDIF using a connection that has the provider set
> to Apache Directory LDAP Client API, Studio will silently drop and ignore the
> following value in the LDIF file:
> {{description:: VGjDtmlzIMOlcyBhIHTDpHN0IHllcw==}}
> No errors are shown, the value will show up in the log and everything will
> look OK but if you check the actual entry in the LDAP server the value is
> missing.
> If I switch the provider to JNDI then everything will be OK.
> Tested with:
> * Apache DS 2.0 included in Studio 2.0 M13
> * NetIQ eDirectory 8.8 SP8 patch 7
> * NetIQ eDIrectory 9.0.4
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
