JXplorer should correctly encode non-english characters into UTF-8,
as per the spec; it's been tested with everything from French to
Chinese. "/ufffd' is a java unicode character escape sequence, which
should never be produced by JX, but might be produced by some java
code somewhere that is trying to 'make safe' a UTF-8 string - this
would be consistent with the ' ' -> '%20' behaviour.
- Chris Betts (JX dev team)
On 13/03/2006, at 7:59 PM, Tony Blanchard (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DIRSERVER-591?
page=comments#action_12370132 ]
Tony Blanchard commented on DIRSERVER-591:
------------------------------------------
Hi Emmanuel,
I did not try with another tool because I have no other tool yet.
Nevertheless, I found the problem on my client code and tried with
JXplorer which has the same pb.
I have seen something to tell you about to reproduce in JXplorer.
First of all, I have ACLs enabled and forgot to tell about it in
environment...
In JXplorer, under groups as admin, create a new entry with classes
Top and groupOfUniqueNames.
Enter the common name like "cn=secrétaire" and valiadate the
creation box. In the right table of JXplorer, add as uniqueMember
"uid=admin, ou=system".
Submit changes to LDAP server. It works and you can look at the
entry event if you look another one and come back to "secrétaire".
Now, log out and login as admin. Go to "secrétaire" and there is an
exception with these details :
javax.naming.NameNotFoundException: [LDAP: error code 32 - failed
on search operation:
SearchRequest
baseDn : 'cn=secr?taire,ou=groups,ou=system'
filter : '(objectClass=*) '
scope : base object
typesOnly : false
no limit
Time Limit : no limit
Deref Aliases : deref Finding Base Obj
attributes :
:
org.apache.directory.shared.ldap.exception.LdapNameNotFoundException:
Attempt to search under non-existant entry: cn=secr?
taire,ou=groups,ou=system
at
org.apache.directory.server.core.exception.ExceptionService.assertHasE
ntry(ExceptionService.java:377)
at
org.apache.directory.server.core.exception.ExceptionService.search
(ExceptionService.java:353)
at org.apache.directory.server.core.interceptor.InterceptorChain
$Entry$1.search(InterceptorChain.java:1257)
at
org.apache.directory.server.core.authz.AuthorizationService.search
(AuthorizationService.java:899)
at org.apache.directory.server.core.interceptor.InterceptorChain
$Entry$1.search(InterceptorChain.java:1257)
at org.apache.directory.server.core.referral.ReferralService.search
(ReferralService.java:905)
at org.apache.directory.server.core.interceptor.InterceptorChain
$Entry$1.search(InterceptorChain.java:1257)
at
org.apache.directory.server.core.authn.AuthenticationService.search
(AuthenticationService.java:388)
at org.apache.directory.server.core.interceptor.InterceptorChain
$Entry$1.search(InterceptorChain.java:1257)
at
org.apache.directory.server.core.normalization.NormalizationService.se
arch(NormalizationService.java:180)
at
org.apache.directory.server.core.interceptor.InterceptorChain.search
(InterceptorChain.java:822)
at
org.apache.directory.server.core.partition.DirectoryPartitionNexusProx
y.search(DirectoryPartitionNexusProxy.java:461)
at
org.apache.directory.server.core.partition.DirectoryPartitionNexusProx
y.search(DirectoryPartitionNexusProxy.java:406)
at org.apache.directory.server.core.jndi.ServerDirContext.search
(ServerDirContext.java:526)
at
org.apache.directory.server.ldap.support.SearchHandler.messageReceived
(SearchHandler.java:265)
at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived
(DemuxingIoHandler.java:128)
at org.apache.directory.server.ldap.LdapProtocolProvider
$LdapProtocolHandler.messageReceived(LdapProtocolProvider.java:431)
at org.apache.mina.common.support.AbstractIoFilterChain
$2.messageReceived(AbstractIoFilterChain.java:189)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageRe
ceived(AbstractIoFilterChain.java:494)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1000
(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl
$1.messageReceived(AbstractIoFilterChain.java:761)
at org.apache.mina.filter.LoggingFilter.messageReceived
(LoggingFilter.java:87)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageRe
ceived(AbstractIoFilterChain.java:494)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1000
(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl
$1.messageReceived(AbstractIoFilterChain.java:761)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived
(ProtocolCodecFilter.java:91)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageRe
ceived(AbstractIoFilterChain.java:494)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1000
(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl
$1.messageReceived(AbstractIoFilterChain.java:761)
at org.apache.mina.filter.ThreadPoolFilter.processEvent
(ThreadPoolFilter.java:665)
at org.apache.mina.filter.ThreadPoolFilter$Worker.processEvents
(ThreadPoolFilter.java:421)
at org.apache.mina.filter.ThreadPoolFilter$Worker.run
(ThreadPoolFilter.java:376)
]; remaining name 'cn=secr taire,ou=groups,ou=system'
If this is not enought to help i will try to install the tool you
tell me about.
Tony
Putting some chars like "é" in common name with JXPlorer or my
client code creates problems
---------------------------------------------------------------------
----------------------
Key: DIRSERVER-591
URL: http://issues.apache.org/jira/browse/DIRSERVER-591
Project: Directory ApacheDS
Type: Bug
Versions: 1.0-RC1
Environment: Win XP SP2
JRE 1.5.0_04
ApacheDS RC1.0
Reporter: Tony Blanchard
It seems the apacheds database does not like "é" chars.
I even think trying to destroy such entries containing such chars
lead to database severe corruption but I have no real and
systematic clue yet.
To reproduce, simply try to put a group with a "é" char in the cn
attribute with JXplorer. Now, try to modify it. Exception araise.
Now, in my client code, I see SearchResult returned with bad
results in getName() or getNameInNameSpace(). It seems it returns
a string with " " replaced by "%20" and "é" char replaced with a
value like /ufffd or something like this.
Nevertheless, if I retrieve the attributes from the SearchResult I
get the correct "cn" value with a correct "é" char in it
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
