You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "nick faiz (JIRA)" <di...@incubator.apache.org> on 2005/06/17 03:01:47 UTC
[jira] Created: (DIREVE-165) searchFilter for 2 Parser failure on name: Antlr exception trace: line 15:7: unexpected char: '#'
searchFilter for 2 Parser failure on name: Antlr exception trace: line 15:7: unexpected char: '#'
-------------------------------------------------------------------------------------------------
Key: DIREVE-165
URL: http://issues.apache.org/jira/browse/DIREVE-165
Project: Directory Server
Type: Bug
Versions: 0.9.1
Reporter: nick faiz
Assigned to: Alex Karasulu
Attachments: test-userbase.ldif
This probably only occurs under a certain config. (see below), so it is possible that the configuration itself is erroneous.
When running a search on a user, represented in LDIF, below, I hit the following stack trace with the following search filter:
search filter: (member=groupB)
Parser failure on name:
groupB
Antlr exception trace:
line 15:7: unexpected char: '#'
at org.apache.ldap.common.name.antlrTypeLexer.nextToken(antlrTypeLexer.java:147)
at antlr.TokenStreamSelector.nextToken(TokenStreamSelector.java:64)
at antlr.TokenBuffer.fill(TokenBuffer.java:69)
at antlr.TokenBuffer.LA(TokenBuffer.java:80)
at antlr.LLkParser.LA(LLkParser.java:52)
at antlr.Parser.match(Parser.java:212)
at org.apache.ldap.common.name.antlrNameParser.attributeTypeAndValue(antlrNameParser.java:179)
dn: uid=ldapusera,ou=users,ou=system
cn: ldapusera
sn: Surname1
givenname: ldapusera
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
ou: Human Resources
ou: People
l: Atlassian test subject
uid: ldapusera
mail: ldapusera@testingarea.org
userpassword: passa
title: groupA
title: groupB
member: groupA
The search filter successfully works on title, uid, and mail. Perhaps I'm making a mistake by trying to incorporate the member attribute, from RFC 2256 (2.5.4.31), into an inetorgperson entity? All the same, the error message is mysterious ...
This problem is occurring on 0.9.1 main, before the addition of the Spring config. layer (i.e., Im still setting up with a server.properties file).
Cheers,
Nick
--
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] Updated: (DIREVE-165) searchFilter for 2 Parser failure on name: Antlr exception trace: line 15:7: unexpected char: '#'
Posted by "nick faiz (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIREVE-165?page=all ]
nick faiz updated DIREVE-165:
-----------------------------
Attachment: test-userbase.ldif
> searchFilter for 2 Parser failure on name: Antlr exception trace: line 15:7: unexpected char: '#'
> -------------------------------------------------------------------------------------------------
>
> Key: DIREVE-165
> URL: http://issues.apache.org/jira/browse/DIREVE-165
> Project: Directory Server
> Type: Bug
> Versions: 0.9.1
> Reporter: nick faiz
> Assignee: Alex Karasulu
> Attachments: test-userbase.ldif
>
> This probably only occurs under a certain config. (see below), so it is possible that the configuration itself is erroneous.
> When running a search on a user, represented in LDIF, below, I hit the following stack trace with the following search filter:
> search filter: (member=groupB)
> Parser failure on name:
> groupB
> Antlr exception trace:
> line 15:7: unexpected char: '#'
> at org.apache.ldap.common.name.antlrTypeLexer.nextToken(antlrTypeLexer.java:147)
> at antlr.TokenStreamSelector.nextToken(TokenStreamSelector.java:64)
> at antlr.TokenBuffer.fill(TokenBuffer.java:69)
> at antlr.TokenBuffer.LA(TokenBuffer.java:80)
> at antlr.LLkParser.LA(LLkParser.java:52)
> at antlr.Parser.match(Parser.java:212)
> at org.apache.ldap.common.name.antlrNameParser.attributeTypeAndValue(antlrNameParser.java:179)
> dn: uid=ldapusera,ou=users,ou=system
> cn: ldapusera
> sn: Surname1
> givenname: ldapusera
> objectclass: top
> objectclass: person
> objectclass: organizationalPerson
> objectclass: inetOrgPerson
> ou: Human Resources
> ou: People
> l: Atlassian test subject
> uid: ldapusera
> mail: ldapusera@testingarea.org
> userpassword: passa
> title: groupA
> title: groupB
> member: groupA
> The search filter successfully works on title, uid, and mail. Perhaps I'm making a mistake by trying to incorporate the member attribute, from RFC 2256 (2.5.4.31), into an inetorgperson entity? All the same, the error message is mysterious ...
> This problem is occurring on 0.9.1 main, before the addition of the Spring config. layer (i.e., Im still setting up with a server.properties file).
> Cheers,
> Nick
--
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: Adding a LDAP schema definition.
Posted by Tony Blanchard <bl...@wanadoo.fr>.
Yes, I saw that yesterday evening.
At first time I did not know where the error was.
But now it is sure JXPlorer ans apacheds are ok. It was my own
configuration error...
Know I can compile my schemas separatly from apache ds core and declare
it in the server configuration file.
JXPlorer shows the right added Objects and atts.
Thanks for the given help and details
Tony Blanchard
Chris Betts a écrit :
> Hi Tony,
>
> I think you've already been well answered by others; but for
> question one, yes, JX should show you the new object class when
> creating a new entry - JX doesn't have much 'built in' schema. To
> double check, you can browse the schema that JX has read from the
> directory using the right hand 'schema' tab in the left tree view
> pane. Also remember that you will need to reconnect to re-read the
> schema, as JX caches it when it first connects (*cough* the reason
> for the connection being a bit slow).
>
> - Chris
>
> On 17/06/2005, at 6:01 PM, Tony Blanchard wrote:
>
>> Hi,
>>
>> I tried to add a new type of object in LDAP by adding a schema and I
>> found that it needs to be compiled with core apacheds project.
>>
>> First question, my schema is correctly compiled but my new object
>> does not appears in JXPlorer objectclass choice when creating new
>> entry.
>> Is it normal or JXPlorer should find my schema definition in server
>> and then show me my new object ?
>>
>> Second question, is there any means to compile it separatly from the
>> apacheds project and add the schema definition dynmically on server
>> startup?
>>
>> Thanks
>> Tony Blanchard
>>
>>
>>
>>
>>
>
>
>
>
Re: Adding a LDAP schema definition.
Posted by Chris Betts <ch...@pegacat.com>.
Hi Tony,
I think you've already been well answered by others; but for
question one, yes, JX should show you the new object class when
creating a new entry - JX doesn't have much 'built in' schema. To
double check, you can browse the schema that JX has read from the
directory using the right hand 'schema' tab in the left tree view
pane. Also remember that you will need to reconnect to re-read the
schema, as JX caches it when it first connects (*cough* the reason
for the connection being a bit slow).
- Chris
On 17/06/2005, at 6:01 PM, Tony Blanchard wrote:
> Hi,
>
> I tried to add a new type of object in LDAP by adding a schema and
> I found that it needs to be compiled with core apacheds project.
>
> First question, my schema is correctly compiled but my new object
> does not appears in JXPlorer objectclass choice when creating new
> entry.
> Is it normal or JXPlorer should find my schema definition in server
> and then show me my new object ?
>
> Second question, is there any means to compile it separatly from
> the apacheds project and add the schema definition dynmically on
> server startup?
>
> Thanks
> Tony Blanchard
>
>
>
>
>
Re: Adding a LDAP schema definition.
Posted by Tony Blanchard <bl...@wanadoo.fr>.
I just tried it and it works.
I did not know that on classpath and jar options but there were no
message on it... As I never work in command line.
I have a subsidiary question related to this thread.
Why not separating bootstrap functionnalities from core ? This would be
more faster to compile core this would be easier to understand schema's
building.
If you are interested in, I made a maven project wich is separated from
core. The only thing to change is to put bootstrap classes in it instead
of making a dependency to core...
Tell me for that,
Thanks again,
Tony Blanchard
Trustin Lee a écrit :
> Tony,
>
> 2005/6/18, Tony Blanchard <bltony@wanadoo.fr <ma...@wanadoo.fr>>:
>
> java -classpath c:\MyJarPath\MyJar.jar -jar
> c:\apachedsMainPath\apacheds-main-0.9.1-SNAPSHOT.jar
> C:\ConfFilePath.xml
>
>
> -classpath and -jar option cannot be specified together. -classpath
> option will be ignored. Could you please do like this?
>
> java -cp myjar.jar;apacheds-main.jar org.apache.ldap.server.ServerMain
> conffile.xml
>
> I hope this helps you.
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
Re: Adding a LDAP schema definition.
Posted by Trustin Lee <tr...@gmail.com>.
Tony,
2005/6/18, Tony Blanchard <bl...@wanadoo.fr>:
>
> java -classpath c:\MyJarPath\MyJar.jar -jar
> c:\apachedsMainPath\apacheds-main-0.9.1-SNAPSHOT.jar C:\ConfFilePath.xml
-classpath and -jar option cannot be specified together. -classpath option
will be ignored. Could you please do like this?
java -cp myjar.jar;apacheds-main.jar org.apache.ldap.server.ServerMain
conffile.xml
I hope this helps you.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Adding a LDAP schema definition.
Posted by Tony Blanchard <bl...@wanadoo.fr>.
Trustin,
As you asked me I tell you it do not work. But I may have missed
something ...
I made a maven project to build the generated class from my schema
defintion : myschema.schema
I obtained a correct jar with the following classes in it :
org.apache.ldap.server.schema.bootstrap.MyschemaAttributeTypeProducer.class
org.apache.ldap.server.schema.bootstrap.MyschemaComparatorProducer.class
org.apache.ldap.server.schema.bootstrap.MyschemaDitContentRuleProducer.class
org.apache.ldap.server.schema.bootstrap.MyschemaDitStructureRuleProducer.class
org.apache.ldap.server.schema.bootstrap.MyschemaMatchingRuleProducer.class
org.apache.ldap.server.schema.bootstrap.MyschemaMatchingRuleUseProducer.class
org.apache.ldap.server.schema.bootstrap.MyschemaNameFormProducer.class
org.apache.ldap.server.schema.bootstrap.MyschemaNormalizerProducer.class
org.apache.ldap.server.schema.bootstrap.MyschemaObjectClassProducer.class
org.apache.ldap.server.schema.bootstrap.MyschemaObjectFactoryProducer.class
org.apache.ldap.server.schema.bootstrap.MyschemaSchema.class
org.apache.ldap.server.schema.bootstrap.MyschemaStateFactoryProducer.class
org.apache.ldap.server.schema.bootstrap.MyschemaSyntaxCheckerProducer.class
org.apache.ldap.server.schema.bootstrap.MyschemaSyntaxProducer.class
I then modified my server's launch bat file like this :
java -classpath c:\MyJarPath\MyJar.jar -jar
c:\apachedsMainPath\apacheds-main-0.9.1-SNAPSHOT.jar C:\ConfFilePath.xml
I added the following line to the configuration file :
<bean class=" org.apache.ldap.server.schema.bootstrap.MyschemaSchema"/>
And when I launch my batch file, the class loader do not find the class
"org.apache.ldap.server.schema.bootstrap.MyschemaSchema"...
Any idea ?
Thanks,
Tony Blanchard
Trustin Lee a écrit :
> Hi,
>
> 2005/6/17, Tony Blanchard <bltony@wanadoo.fr <ma...@wanadoo.fr>>:
>
> Hi Trustin,
>
> I am affraid I did not even if I do not use programmation but an xml
> configuration file.
>
> Nevertheless my second question still opened.
> May I compile some new Schema class in a jar and add a configuration
> line like
> <bean class=myjarpackages.myschema"/> after moving my jar to the
> server
> classpath or something like this ?
>
>
> Yes, you can do that, and it should work. Please let us know if it
> doesn't work. Here's an example:
>
> <property name="bootstrapSchemas">
> <set>
> <bean
> class="org.apache.ldap.server.schema.bootstrap.AutofsSchema"/>
> <bean
> class="org.apache.ldap.server.schema.bootstrap.CorbaSchema "/>
> <bean class="org.apache.ldap.server.schema.bootstrap.CoreSchema"/>
> <bean
> class="org.apache.ldap.server.schema.bootstrap.CosineSchema"/>
> <bean class="
> org.apache.ldap.server.schema.bootstrap.ApacheSchema"/>
> <bean
> class="org.apache.ldap.server.schema.bootstrap.InetorgpersonSchema"/>
> <bean
> class="org.apache.ldap.server.schema.bootstrap.JavaSchema "/>
> <bean
> class="org.apache.ldap.server.schema.bootstrap.Krb5kdcSchema"/>
> <bean class="org.apache.ldap.server.schema.bootstrap.NisSchema"/>
> <bean class="
> org.apache.ldap.server.schema.bootstrap.SystemSchema"/>
> <bean class="xxx.yyy.zzz.MyFavoriteSchema"/>
> </set>
> </property>
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
Re: Adding a LDAP schema definition.
Posted by Trustin Lee <tr...@gmail.com>.
Hi,
2005/6/17, Tony Blanchard <bl...@wanadoo.fr>:
>
> Hi Trustin,
>
> I am affraid I did not even if I do not use programmation but an xml
> configuration file.
>
> Nevertheless my second question still opened.
> May I compile some new Schema class in a jar and add a configuration
> line like
> <bean class=myjarpackages.myschema"/> after moving my jar to the server
> classpath or something like this ?
Yes, you can do that, and it should work. Please let us know if it doesn't
work. Here's an example:
<property name="bootstrapSchemas">
<set>
<bean class="org.apache.ldap.server.schema.bootstrap.AutofsSchema"/>
<bean class="org.apache.ldap.server.schema.bootstrap.CorbaSchema"/>
<bean class="org.apache.ldap.server.schema.bootstrap.CoreSchema"/>
<bean class="org.apache.ldap.server.schema.bootstrap.CosineSchema"/>
<bean class="org.apache.ldap.server.schema.bootstrap.ApacheSchema"/>
<bean class="org.apache.ldap.server.schema.bootstrap.InetorgpersonSchema"/>
<bean class="org.apache.ldap.server.schema.bootstrap.JavaSchema"/>
<bean class="org.apache.ldap.server.schema.bootstrap.Krb5kdcSchema"/>
<bean class="org.apache.ldap.server.schema.bootstrap.NisSchema"/>
<bean class="org.apache.ldap.server.schema.bootstrap.SystemSchema"/>
<bean class="xxx.yyy.zzz.MyFavoriteSchema"/>
</set>
</property>
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Adding a LDAP schema definition.
Posted by Tony Blanchard <bl...@wanadoo.fr>.
Hi Trustin,
I am affraid I did not even if I do not use programmation but an xml
configuration file.
Nevertheless my second question still opened.
May I compile some new Schema class in a jar and add a configuration
line like
<bean class=myjarpackages.myschema"/> after moving my jar to the server
classpath or something like this ?
Thanks for your answer.
Tony Blanchard
Trustin Lee a écrit :
> Hi,
>
> 2005/6/17, Tony Blanchard <bltony@wanadoo.fr <ma...@wanadoo.fr>>:
>
> Hi,
>
> I tried to add a new type of object in LDAP by adding a schema and I
> found that it needs to be compiled with core apacheds project.
>
>
> Did you configure ApacheDS correctly? To add bootstrap schemas:
>
> MutableStartupConfiguration cfg = new MutableStartupConfiguration();
> Set schemas = cfg.getBootstrapSchemas(); // get default schemas
> schemas.add( new MyFavoriteSchema() );
> cfg.setBootstrapSchemas( schemas );
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
Re: Adding a LDAP schema definition.
Posted by Trustin Lee <tr...@gmail.com>.
Hi,
2005/6/17, Tony Blanchard <bl...@wanadoo.fr>:
>
> Hi,
>
> I tried to add a new type of object in LDAP by adding a schema and I
> found that it needs to be compiled with core apacheds project.
Did you configure ApacheDS correctly? To add bootstrap schemas:
MutableStartupConfiguration cfg = new MutableStartupConfiguration();
Set schemas = cfg.getBootstrapSchemas(); // get default schemas
schemas.add( new MyFavoriteSchema() );
cfg.setBootstrapSchemas( schemas );
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Adding a LDAP schema definition.
Posted by Tony Blanchard <bl...@wanadoo.fr>.
Hi,
I tried to add a new type of object in LDAP by adding a schema and I
found that it needs to be compiled with core apacheds project.
First question, my schema is correctly compiled but my new object does
not appears in JXPlorer objectclass choice when creating new entry.
Is it normal or JXPlorer should find my schema definition in server and
then show me my new object ?
Second question, is there any means to compile it separatly from the
apacheds project and add the schema definition dynmically on server startup?
Thanks
Tony Blanchard
[jira] Updated: (DIREVE-165) Parser failure on name: Antlr exception trace: line 15:7: unexpected char: '#'
Posted by "Alex Karasulu (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIREVE-165?page=all ]
Alex Karasulu updated DIREVE-165:
---------------------------------
Summary: Parser failure on name: Antlr exception trace: line 15:7: unexpected char: '#' (was: searchFilter for 2 Parser failure on name: Antlr exception trace: line 15:7: unexpected char: '#')
<biv> hey aok - is it possible to have DIREVE-165 edited to have a more readable title? Can you get rid of the leading 'searchFilter for 2 '? I dont have the editissue perm.<biv> hey aok - is it possible to have DIREVE-165 edited to have a more readable title? Can you get rid of the leading 'searchFilter for 2 '? I dont have the editissue perm.
<aok> ok let me look
<biv> tnx
<aok> ok let me look
<biv> tnx
> Parser failure on name: Antlr exception trace: line 15:7: unexpected char: '#'
> ------------------------------------------------------------------------------
>
> Key: DIREVE-165
> URL: http://issues.apache.org/jira/browse/DIREVE-165
> Project: Directory Server
> Type: Bug
> Versions: 0.9.1
> Reporter: nick faiz
> Assignee: Alex Karasulu
> Attachments: test-userbase.ldif
>
> This probably only occurs under a certain config. (see below), so it is possible that the configuration itself is erroneous.
> When running a search on a user, represented in LDIF, below, I hit the following stack trace with the following search filter:
> search filter: (member=groupB)
> Parser failure on name:
> groupB
> Antlr exception trace:
> line 15:7: unexpected char: '#'
> at org.apache.ldap.common.name.antlrTypeLexer.nextToken(antlrTypeLexer.java:147)
> at antlr.TokenStreamSelector.nextToken(TokenStreamSelector.java:64)
> at antlr.TokenBuffer.fill(TokenBuffer.java:69)
> at antlr.TokenBuffer.LA(TokenBuffer.java:80)
> at antlr.LLkParser.LA(LLkParser.java:52)
> at antlr.Parser.match(Parser.java:212)
> at org.apache.ldap.common.name.antlrNameParser.attributeTypeAndValue(antlrNameParser.java:179)
> dn: uid=ldapusera,ou=users,ou=system
> cn: ldapusera
> sn: Surname1
> givenname: ldapusera
> objectclass: top
> objectclass: person
> objectclass: organizationalPerson
> objectclass: inetOrgPerson
> ou: Human Resources
> ou: People
> l: Atlassian test subject
> uid: ldapusera
> mail: ldapusera@testingarea.org
> userpassword: passa
> title: groupA
> title: groupB
> member: groupA
> The search filter successfully works on title, uid, and mail. Perhaps I'm making a mistake by trying to incorporate the member attribute, from RFC 2256 (2.5.4.31), into an inetorgperson entity? All the same, the error message is mysterious ...
> This problem is occurring on 0.9.1 main, before the addition of the Spring config. layer (i.e., Im still setting up with a server.properties file).
> Cheers,
> Nick
--
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-381) Parser failure on name: Antlr
exception trace: line 15:7: unexpected char: '#'
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny closed DIRSERVER-381.
---------------------------------------
Closing all issues created in 2005 and before which are marked resolved
> Parser failure on name: Antlr exception trace: line 15:7: unexpected char: '#'
> ------------------------------------------------------------------------------
>
> Key: DIRSERVER-381
> URL: https://issues.apache.org/jira/browse/DIRSERVER-381
> Project: Directory ApacheDS
> Issue Type: Bug
> Reporter: Nick Faiz
> Assigned To: Alex Karasulu
> Attachments: test-userbase.ldif
>
>
> This probably only occurs under a certain config. (see below), so it is possible that the configuration itself is erroneous.
> When running a search on a user, represented in LDIF, below, I hit the following stack trace with the following search filter:
> search filter: (member=groupB)
> Parser failure on name:
> groupB
> Antlr exception trace:
> line 15:7: unexpected char: '#'
> at org.apache.ldap.common.name.antlrTypeLexer.nextToken(antlrTypeLexer.java:147)
> at antlr.TokenStreamSelector.nextToken(TokenStreamSelector.java:64)
> at antlr.TokenBuffer.fill(TokenBuffer.java:69)
> at antlr.TokenBuffer.LA(TokenBuffer.java:80)
> at antlr.LLkParser.LA(LLkParser.java:52)
> at antlr.Parser.match(Parser.java:212)
> at org.apache.ldap.common.name.antlrNameParser.attributeTypeAndValue(antlrNameParser.java:179)
> dn: uid=ldapusera,ou=users,ou=system
> cn: ldapusera
> sn: Surname1
> givenname: ldapusera
> objectclass: top
> objectclass: person
> objectclass: organizationalPerson
> objectclass: inetOrgPerson
> ou: Human Resources
> ou: People
> l: Atlassian test subject
> uid: ldapusera
> mail: ldapusera@testingarea.org
> userpassword: passa
> title: groupA
> title: groupB
> member: groupA
> The search filter successfully works on title, uid, and mail. Perhaps I'm making a mistake by trying to incorporate the member attribute, from RFC 2256 (2.5.4.31), into an inetorgperson entity? All the same, the error message is mysterious ...
> This problem is occurring on 0.9.1 main, before the addition of the Spring config. layer (i.e., Im still setting up with a server.properties file).
> Cheers,
> Nick
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DIREVE-165) Parser failure on name: Antlr exception trace: line 15:7: unexpected char: '#'
Posted by "Alex Karasulu (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIREVE-165?page=all ]
Alex Karasulu resolved DIREVE-165:
----------------------------------
Fix Version: 0.9.2
Resolution: Invalid
This is not a bug. You are incorrectly using the member attribute. According to 2256 this is the following definition for a member attribute:
attributetype ( 2.5.4.31 NAME 'member'
DESC 'RFC2256: member of a group'
SUP distinguishedName )
Notice that member values must be distinguished names. So your LDIF is invalid since the member values are not correctt distinguished names. The server basically chokes trying to read a DN for groupB in this incorrect filter of (member=groupB). If you used the proper values in the LDAP for the member attribute the following filter would work:
(member=cn=groupB,ou=groups,ou=system)
Once I fixed the LDIF and ran this search filter it all worked like a champion.
> Parser failure on name: Antlr exception trace: line 15:7: unexpected char: '#'
> ------------------------------------------------------------------------------
>
> Key: DIREVE-165
> URL: http://issues.apache.org/jira/browse/DIREVE-165
> Project: Directory Server
> Type: Bug
> Versions: 0.9.1
> Reporter: Nick Faiz
> Assignee: Alex Karasulu
> Fix For: 0.9.2
> Attachments: test-userbase.ldif
>
> This probably only occurs under a certain config. (see below), so it is possible that the configuration itself is erroneous.
> When running a search on a user, represented in LDIF, below, I hit the following stack trace with the following search filter:
> search filter: (member=groupB)
> Parser failure on name:
> groupB
> Antlr exception trace:
> line 15:7: unexpected char: '#'
> at org.apache.ldap.common.name.antlrTypeLexer.nextToken(antlrTypeLexer.java:147)
> at antlr.TokenStreamSelector.nextToken(TokenStreamSelector.java:64)
> at antlr.TokenBuffer.fill(TokenBuffer.java:69)
> at antlr.TokenBuffer.LA(TokenBuffer.java:80)
> at antlr.LLkParser.LA(LLkParser.java:52)
> at antlr.Parser.match(Parser.java:212)
> at org.apache.ldap.common.name.antlrNameParser.attributeTypeAndValue(antlrNameParser.java:179)
> dn: uid=ldapusera,ou=users,ou=system
> cn: ldapusera
> sn: Surname1
> givenname: ldapusera
> objectclass: top
> objectclass: person
> objectclass: organizationalPerson
> objectclass: inetOrgPerson
> ou: Human Resources
> ou: People
> l: Atlassian test subject
> uid: ldapusera
> mail: ldapusera@testingarea.org
> userpassword: passa
> title: groupA
> title: groupB
> member: groupA
> The search filter successfully works on title, uid, and mail. Perhaps I'm making a mistake by trying to incorporate the member attribute, from RFC 2256 (2.5.4.31), into an inetorgperson entity? All the same, the error message is mysterious ...
> This problem is occurring on 0.9.1 main, before the addition of the Spring config. layer (i.e., Im still setting up with a server.properties file).
> Cheers,
> Nick
--
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