[jira] Closed: (DIRSERVER-178) Embedded ApacheDS fails on parser exception if provider URL is an actual URL

["Alex Karasulu (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/jira/browse/DIRSERVER-178?page=all ]

Alex Karasulu closed DIRSERVER-178.
-----------------------------------

    Fix Version/s: 1.1.0
                   1.0-RC4
       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: http://issues.apache.org/jira/browse/DIRSERVER-178
>             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 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