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:
org.apache.directory.shared.ldap.model.exception.LdapConfigurationException:
ERR_171 Failed to bind an LDAP service (1,024) to the service
registry.
at
org.apache.directory.server.ldap.LdapServer.startNetwork(LdapServer.java:625)
at
org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:466)
at
org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:217)
at
org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:260)
at
org.apache.directory.server.core.integ.FrameworkRunner.run(FrameworkRunner.java:222)
...
Caused by: java.net.BindException: 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 !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
