directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <m...@stefan-seelmann.de>
Subject Bind Address of @CreateLdapServer/@CreateTransport
Date Sat, 26 Dec 2015 22:05:06 GMT
Hi,

in Studio integration tests we use our own ApacheDS test framwork with
@CreateLdapServer and @CreateTransport annotations, for example

@RunWith(FrameworkRunner.class)
@CreateLdapServer(transports =
    { @CreateTransport(protocol = "LDAP"),
      @CreateTransport(protocol = "LDAPS") })

Since upgrade to ApacheDS 2.0.0-M21 I noticed that the tests failed on
Jenkins, on a Linux server, and also on my Mac, but it works on my main
Linux Laptop. After some debugging I found out that the started ApacheDS
only binds to the public interface but not to the loopback device, and
in the Studio tests I create a connection with host "localhost" and then
only get a "connection refused".

One workaround I tried is to bind to all network interfaces by changing
annotations to this:

@CreateLdapServer(transports =
    { @CreateTransport(address = "0.0.0.0", protocol = "LDAP"),
+        @CreateTransport(address = "0.0.0.0", protocol = "LDAPS") })

In ApacheDS tests i noticed that we don't use "localhost" but lookup the
hostname by our old friend

    InetAddress.getLocalHost().getHostName()

That would be the 2nd change I can do to fix Studio tests.

But I wonder if it is good that the ApacheDS started by the test
framworks binds to public interace at all? I mean the default use case
is to run tests on the same hosts. I think it is not a good idea to bind
to public interface at all.

Thoughts?

Kind Regards,
Stefan

Mime
View raw message