directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Faiz (JIRA)" <>
Subject [jira] Created: (DIRLDAP-46) Embedded ApacheDS fails on parser exception if provider URL is an actual URL
Date Mon, 01 Aug 2005 04:08:36 GMT
Embedded ApacheDS fails on parser exception if provider URL is an actual URL

         Key: DIRLDAP-46
     Project: Directory LDAP
        Type: Bug
  Components: Common  
    Versions: 0.9.1    
    Reporter: Nick Faiz
 Assigned to: Alex Karasulu 

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:
Antlr exception trace:
line 22:5: unexpected char: ':'
	at antlr.TokenStreamSelector.nextToken(

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


This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message