directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Test Annotation Feedback
Date Mon, 01 Aug 2011 22:23:37 GMT
On 8/1/11 10:43 PM, Stefan Seelmann wrote:
> Hi guys,
> I'd like to share some feedback with some test annotations fun I had today.
> I had to write some integration tests for a custom Tomcat Realm. In
> that tests I have to startup three servers:
> - Tomcat
> - SQL Database (Derby)
> - LDAP
> Of course I use ApacheDS for the LDAP part. I started to use
> annotations but for multiple reasons that didn't work for me:
> 1st)
> I just added the the following two annotations
>      @RunWith(FrameworkRunner.class)
>      @CreateLdapServer
> When starting the tests I got the following stacktrace at the console:
> ERR_171 Failed to bind an LDAP service (1,024) to the service
> registry.
> 	at
> 	at
> 	at
> 	at
> 	at
> 	...
> Caused by: Address already in use
> 	...
> The reason is that both, LDAP and LDAPS transports try to bind the
> same port (1024). As soon as I added the transport annotations it
> worked:
>      @CreateLdapServer(transports = {
>          @CreateTransport(protocol = "LDAP"),
>          @CreateTransport(protocol = "LDAPS") } )
> I think there should be a better default, right?

Absolutely. In fact, we *must* get rid of the AvailablePortFinder, which 
is not only useless, but also problematic.

I have incidentally modified the crrent @nnotation today and removed 
those 1024 from the code. Funny that you raised the issue at the same 
time :)
> 2nd)
> My test class needs to extend another class, so I'm not able to extend
> AbstrctLdapTestUnit. But the FrameworkRunner forces me to define some
> fields and methods:
>      public static boolean isRunInSuite;
>      public static void setService( DirectoryService service );
>      public static void setLdapServer( LdapServer server );
>      public static void setKdcServer( KdcServer server );
> Please note that there is a inconsistence: the isRunInSuite must be a
> field while for the other properties setters are used. In my case I
> only need the LDAP server to be able to get the used port, the other
> properties are useless. I wonder if those properties should be
> optional?
Th eservice is mandatory for the LdapServer, but the KdcServer should 
definitively be optionnal.
> 3rd)
> For my test class annotations don't fit well because the other server
> (Tomcat and Derby DB) need to be setup programatically. I also wanted
> to setup ApacheDS programatically because I wanted a more homogenous
> setup/teardown. So I added the apacheds-service to the dependencies
> and just used
>          ApacheDsService apacheds = new ApacheDsService();
>          InstanceLayout instanceLayout = new InstanceLayout(dir);
>          apacheds.start( instanceLayout );
> and have a running LDAP server. This is quite easy. The drawback is
> that the apacheds-service.jar is a shared Jar that contains all the
> dependencies (antlr, servlet-api, ehcache, commons-*, activemq,
> osgi/felix, log4j, jetty, etc.). In my case that works but in other
> cases that may lead to conflicts with other dependencies.
OSGi is the way to go, here... This is something we expect to wok on as 
soon as we get ADS-2.0.0-M2 out, in the next few days.
> To sum up, I think the annotation approach works well for the ApacheDS
> internal tests and also for test where only a LDAP server is required.
> For more complex test setups I'd prefer to configure ApacheDS
> programmatically.
We have to clarify this aspect. I have to work on tests in august and 
september, so expect this part of the code to be cleaned up.

Thanks for the feedback, Stefan !

Emmanuel L├ęcharny

View raw message