Major Description
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