You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Tony Blanchard (JIRA)" <ji...@apache.org> on 2006/03/10 17:06:41 UTC
[jira] Created: (DIRSERVER-591) Putting some chars like "é" in common name with JXPlorer or my client code creates problems
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
Re: [jira] Commented: (DIRSERVER-591) Putting some chars like "é" in common name with JXPlorer or my client code creates problems
Posted by Emmanuel Lecharny <el...@gmail.com>.
Chris Betts a écrit :
> Hi Folks,
>
> you're probably on top of this already, but if it helps:
>
> a) JX correctly read/writes non ascii characters into UTF-8 without
> any stress (we test for this, and I've just tried it against another
> directory)
> b) the '/ufffd' is a java escape code for a unicode character - you
> should be able to convert it to UTF-8 using a string constructor like
> 'new String("/ufffd random stuff", "UTF-8")'.
>
> good luck :-)
>
> - Chris
Thanks Chris !
My guess is that we may have a problem for modification of an attribute
that is also a part of the DN.
This is why I need a test case to be able to reproduce the problem, and
also to be sure that it does not popup for the next releases ;)
EmmanUel.
Re: [jira] Commented: (DIRSERVER-591) Putting some chars like "é" in common name with JXPlorer or my client code creates problems
Posted by Chris Betts <ch...@pegacat.com>.
Hi Folks,
you're probably on top of this already, but if it helps:
a) JX correctly read/writes non ascii characters into UTF-8 without
any stress (we test for this, and I've just tried it against another
directory)
b) the '/ufffd' is a java escape code for a unicode character - you
should be able to convert it to UTF-8 using a string constructor like
'new String("/ufffd random stuff", "UTF-8")'.
good luck :-)
- Chris
(jxplorer dev)
On 25/06/2006, at 11:03 PM, Emmanuel Lecharny (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DIRSERVER-591?
> page=comments#action_12417678 ]
>
> Emmanuel Lecharny commented on DIRSERVER-591:
> ---------------------------------------------
>
> I don't know about JXplorer, but with LdapBrowser, if you modify an
> entry (let say cn=lecharny, ou=users, ou=system to cn=lécharny,
> ou=users, ou=system), it works if you select the 'with children'
> option.
>
> We must create a test case for this one, I think.
>
> (tested on 1.0-RC4-SNAPSHOT)
>
>> 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
>
[jira] Commented: (DIRSERVER-591) Putting some chars like "é" in common name with JXPlorer or my client code creates problems
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-591?page=comments#action_12417678 ]
Emmanuel Lecharny commented on DIRSERVER-591:
---------------------------------------------
I don't know about JXplorer, but with LdapBrowser, if you modify an entry (let say cn=lecharny, ou=users, ou=system to cn=lécharny, ou=users, ou=system), it works if you select the 'with children' option.
We must create a test case for this one, I think.
(tested on 1.0-RC4-SNAPSHOT)
> 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
[jira] Resolved: (DIRSERVER-591) Putting some chars like "é" in common name with JXPlorer or my client code creates problems
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-591?page=all ]
Emmanuel Lecharny resolved DIRSERVER-591.
-----------------------------------------
Resolution: Cannot Reproduce
I have tested the server - in branches/apacheds/1.0-trunks, which will be the 1.0-RC4 release -, following the steps in jexplorer; (creating a group where cn=secrétaire, etc ...), but I can't reproduce the problem.
Can you confirm that it has been fixed? If it's not, feel free to repoen the issue.
> 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
> Issue Type: Bug
> Affects Versions: 1.0-RC1
> Environment: Win XP SP2
> JRE 1.5.0_04
> ApacheDS RC1.0
> Reporter: Tony Blanchard
> Assigned To: Emmanuel Lecharny
>
> 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
Re: [jira] Commented: (DIRSERVER-591) Putting some chars like "é" in common name with JXPlorer or my client code creates problems
Posted by Chris Betts <ch...@pegacat.com>.
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
>
[jira] Commented: (DIRSERVER-591) Putting some chars like "é" in common name with JXPlorer or my client code creates problems
Posted by "Tony Blanchard (JIRA)" <ji...@apache.org>.
[ 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.assertHasEntry(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.search(NormalizationService.java:180)
at org.apache.directory.server.core.interceptor.InterceptorChain.search(InterceptorChain.java:822)
at org.apache.directory.server.core.partition.DirectoryPartitionNexusProxy.search(DirectoryPartitionNexusProxy.java:461)
at org.apache.directory.server.core.partition.DirectoryPartitionNexusProxy.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.callNextMessageReceived(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.callNextMessageReceived(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.callNextMessageReceived(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
[jira] Commented: (DIRSERVER-591) Putting some chars like "é" in common name with JXPlorer or my client code creates problems
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-591?page=comments#action_12369944 ]
Emmanuel Lecharny commented on DIRSERVER-591:
---------------------------------------------
Tony,
have you ried with another tool than jxplorer? Let's say LdapBrowser, or just a simple ldif file...
I think it should work, but there may be a bug somewhere... Could you isolate the problem you experienced with jxplorer and reproduce it with ldapbrowser?
Emmanuel Lécharny (with a 'é', testé et approuvé sur ADS :)
> 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
[jira] Closed: (DIRSERVER-591) Putting some chars like "é" in common name with JXPlorer or my client code creates problems
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny closed DIRSERVER-591.
---------------------------------------
1.0 has been released more than 2 years ago ...
> Putting some chars like "é" in common name with JXPlorer or my client code creates problems
> -------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-591
> URL: https://issues.apache.org/jira/browse/DIRSERVER-591
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.0-RC1
> Environment: Win XP SP2
> JRE 1.5.0_04
> ApacheDS RC1.0
> Reporter: Tony Blanchard
> Assignee: Emmanuel Lecharny
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRSERVER-591) Putting some chars like "é" in common name with JXPlorer or my client code creates problems
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-591?page=all ]
Emmanuel Lecharny reassigned DIRSERVER-591:
-------------------------------------------
Assignee: Emmanuel Lecharny
> 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
> Issue Type: Bug
> Affects Versions: 1.0-RC1
> Environment: Win XP SP2
> JRE 1.5.0_04
> ApacheDS RC1.0
> Reporter: Tony Blanchard
> Assigned To: Emmanuel Lecharny
>
> 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