[ http://issues.apache.org/jira/browse/DIRLDAP-46?page=comments#action_12318587 ]
Emmanuel Lecharny commented on DIRLDAP-46: ------------------------------------------ I have a brand need LDAP URL parser which contains main little parsers for every pieces to be parsed : - parseHost - parsePort - parseAttributes - parseExtensions - parseFilter - parseScope - parseDN Those method are actually provate, but the parser could be modified to be used as a general parser. > Embedded ApacheDS fails on parser exception if provider URL is an actual URL > ---------------------------------------------------------------------------- > > Key: DIRLDAP-46 > URL: http://issues.apache.org/jira/browse/DIRLDAP-46 > Project: Directory LDAP > Type: New Feature > Components: Common > Versions: 0.9.1 > Reporter: Nick Faiz > Assignee: Alex Karasulu > Fix For: 0.9.3 > > When setting the JNDI environment for Context.PROVIDER_URL to a valid url, to > connect to an *internal* instance of ApacheDS, a parser exception occurs on > the colon. > A URL, by definition, specifies a protocol - e.g. 'ldap://localhost:10389'. > Inserting a value like this into a JNDI env. to communicate with an instance > of ApacheDS running in the same JVM results in a parser exception: > org.apache.ldap.common.exception.LdapInvalidNameException: Parser failure on > name: > ldap://localhost:10389 > Antlr exception trace: > line 22:5: unexpected char: ':' > at > org.apache.ldap.common.name.antlrTypeLexer.nextToken(antlrTypeLexer.java:154) > at antlr.TokenStreamSelector.nextToken(TokenStreamSelector.java:64) > It seems wrong, intuitively, that a valid URL set in the Context.PROVIDER_URL > property would result in a parser error, regardless of the fact that the ldap > server is running in the same JVM. Setting an invalid URL such as 'ou=system' > into the PROVIDER URL is also unintuitive. > In fact, setting it to a value such as "embedded" results in another parser > exception: > Antlr exception trace: > line 18:9: unexpected char: '#' > In genearl, this also means that the client connection code I use to connect > to ApacheDS, if it is in the same JVM, must be different from client code I > use to connect to external LDAP servers. One of the reasons I have elected to > use ApacheDS is because it useful as a test environment - I have a range of > functional tests which are meant for any LDAP system. ApacheDS is convenient > for quick testing. A typical connection is built from a config file, parsing > a port number and host and constructing a provider URL. This breaks in > ApacheDS and I have had to work around it. So, having chosen ApacheDS as part > of my testing framework I have to alter my tests to run with ApacheDS! :) > Compare this to HSQLDB (via Hibernate), for example. In a test scenario which > is very similar to what I do with Apache DS I specify a URL to connect to the > embedded instance: > myHibernateConfig.setProperty("hibernate.connection.url", > "jdbc:hsqldb:mem:user_testing"). > This same set up principle breaks in ApacheDS. > I would suggest that, at the least, the provider URL be parsed at a higher > level, to prevent the Antlr exception and provide a warning. It would also be > great if a valid URL could be handled in an embedded scenario - > ldap:apacheds:etc > 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
