directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <trus...@gmail.com>
Subject Re: [ApacheDS] How to use a non-networked embedded server?
Date Wed, 21 Dec 2005 08:28:57 GMT
Hello Luke,

I'm sorry for the late response.

Could you please create a JUnit test case for these issues?  I'll really
appreciate it.  Please post them to JIRA.

Thanks in advance,
Trustin

2005/12/17, Luke Taylor <negaton@freesurf.ch>:
>
> Hallo all,
>
> I'm working on the Acegi Security project for the Spring Framework and
> we're keen to use ApacheDS for testing our LDAP security provider.
> I've written a pile of code for this and have a set of JUnit tests which
> I now have running successfully against OpenLDAP and also against an
> ApacheDS server instance which is started from the unit test base class
> (using the Sun provider as the client).
>
> Ideally we would prefer to run with an in-memory embedded server
> (similar to using HSQLDB in this fashion) because it is a lot faster and
>   avoids issues like having to shut down the server (our Maven build in
> particular gets very upset about the embedded server). It seems that
> this may be possible by just by having the client use CoreContextFactory
> to obtain contexts directly rather than the Sun provider. I've managed
> to get some way to achieving this but the behaviour isn't consistent
> with the full stack version and I'm not sure whether this is expected or
> if I'm doing something wrong.
>
> My setup is like this:
>
> I have a simple DIT with a root "dc=acegisecurity,dc=org". This has two
> subcontexts "ou=people" and "ou=groups" for my users and roles
> respectively. When the test base class instantiated, I create a
> MutableStartupConfiguration and add a partition to it with the suffix
> "dc=acegisecurity,dc=org". I then create a context with this
> configuration as follows:
>
>      env.setProperty( Context.PROVIDER_URL, "dc=acegisecurity,dc=org" );
>      env.setProperty( Context.INITIAL_CONTEXT_FACTORY,
>               CoreContextFactory.class.getName());
>      env.putAll( cfg.toJndiEnvironment() );
>
>      serverContext = new InitialDirContext( env );
>
> When I need a context in my tests it is created the same way.
>
> Bind authentication works fine in both scenarios. I have problems with
> two things when trying to use CoreContextFactory :
>
> 1. The name returned by a search. When I do a search for a user in the
> directory, I get back the full DN rather than the name relative to the
> context I search in. So if I call
>
>     ctx.search("ou=people", "(uid={0})", new String[] {"bob"}, ctls);
>
> on a context obtained as above, I get back a SearchResult with name
>
> "uid=bob,ou=people,dc=acegisecurity,dc=org"
>
> whereas with the full server (or OpenLDAP) I get
>
> "uid=bob"
>
> as expected. This then unfortunately leads to an attempt to bind with an
> an unknown DN which causes the infinite recursion problem.
>
> 2. Performing "compare" operations. I had problems with this before, as
> reported in
>
> http://issues.apache.org/jira/browse/DIRLDAP-77
>
> but this now works with the full server, thanks to Emmanuel's speedy
> response. Running the same search code against a context obtained from
> CoreContextFactory fails however. A compare is never performed and the
> search returns an empty enumeration. Is there some way I can get my
> client code (as posted in JIRA):
>
>       SearchControls ctls = new SearchControls();
>       ctls.setReturningAttributes(new String[0]);
>       ctls.setSearchScope(SearchControls.OBJECT_SCOPE);
>
>       String filter = "(userPassword={0})";
>       NamingEnumeration results = ctx.search(dn, filter, new
>             Object[]{password.getBytes()}, ctls);
>
> to trigger a compare call on the context? The compare/search also fails
> for non-binary attributes.
>
> I was also wondering if there was any way of running fully in-memory
> without any persistent storage as it isn't needed for this kind of usage
> and it would avoid the need for clearing up the data files during the
> build.
>
> Any help would be greatly appreciated as we're looking to include LDAP
> support in the forthcoming 1.0 release and ApacheDS seems like our best
> option for an integrated server both for testing and sample applications.
>
> cheers,
>
> Luke.
>
>
>
> --
>   Luke Taylor.                      Monkey Machine Ltd.
>   PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk
>
>


--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C

Mime
View raw message