Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <1586059322.1122869316583.JavaMail.jira@ajax.apache.org>
Date: Mon, 1 Aug 2005 06:08:36 +0200 (CEST)
From: "Nick Faiz (JIRA)" <directory-dev@incubator.apache.org>
To: dev@directory.apache.org
Subject: [jira] Created: (DIRLDAP-46) Embedded ApacheDS fails on parser
 exception if provider URL is an actual URL
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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: 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:
	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