directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <>
Subject [jira] Closed: (DIRSERVER-178) Embedded ApacheDS fails on parser exception if provider URL is an actual URL
Date Sun, 27 Aug 2006 07:59:23 GMT
     [ ]

Alex Karasulu closed DIRSERVER-178.

    Fix Version/s: 1.1.0
       Resolution: Invalid

ApacheDS' embedded JNDI provider does not take a real URL for the provider URL because it's
local to the server.  It makes no sense to provide the host.domain element to the provider.
 This is why we intend to keep it as a simple DN.  Anything else should through an exception.

> Embedded ApacheDS fails on parser exception if provider URL is an actual URL
> ----------------------------------------------------------------------------
>                 Key: DIRSERVER-178
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Bug
>            Reporter: Nick Faiz
>         Assigned To: Alex Karasulu
>             Fix For: 1.1.0, 1.0-RC4
> 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
> 	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
> Cheers,
> Nick

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