directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <directory-...@incubator.apache.org>
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
    [ http://issues.apache.org/jira/browse/DIRLDAP-46?page=comments#action_12318587 ] 

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
parser. 

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


Mime
View raw message