directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] Commented: (DIRLDAP-46) Embedded ApacheDS fails on parser exception if provider URL is an actual URL
Date Fri, 12 Aug 2005 06:32:58 GMT
    [ ] 

Emmanuel Lecharny commented on DIRLDAP-46:

I have a brand need LDAP URL parser which contains main little parsers for every pieces to
be parsed :
- parseHost
- parsePort
- parseAttributes
- parseExtensions
- parseFilter
- parseScope
- parseDN

Those method are actually provate, but the parser could be modified to be used as a general

> Embedded ApacheDS fails on parser exception if provider URL is an actual URL
> ----------------------------------------------------------------------------
>          Key: DIRLDAP-46
>          URL:
>      Project: Directory LDAP
>         Type: New Feature
>   Components: Common
>     Versions: 0.9.1
>     Reporter: Nick Faiz
>     Assignee: Alex Karasulu
>      Fix For: 0.9.3

> 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