Java API - Let Moco choose an available port about moco HOT 14 CLOSED

Good suggestion. Do you have any existing solution?

from moco.

Based on ServerSocket, you can specify a port of "0" to grab an available one, but I'm not 100% sure if Netty has the same concept. I'll take a look and let you know what I find.

from moco.

I tested Moco with port "0" and it seems that Netty works the same and just binds to any available port. Was able to confirm this by executing a future.channel().localAddress() after the bootstrap.bind(.. in MocoServer.java.

Looking for some advice from you Zheng for how the Moco interface should support this.

• Where should somebody be able to query the port that was actually bound to? Maybe the HttpServer object, but currently the HttpServer interface does not support it.. only ActualHttpServer does which would mean a nasty typecast after calling Moco.httpserver(..).
• How should MocoServer.start convey the port number to the HttpServer? Should it have its own getPort method for others to query or some other way?

from moco.

@garrettheel I didn't figure out what is scenario for this. Why do you think it is a good idea to get port dynamically. I need to get port back and then set this port in my unit test case. Comparing to current usage, do you think it makes us easy?

from moco.

@dreamhead I think it depends on the scale of your project. If you have a small number of tests and are always going to run them on the same computer, you can probably hardcode a certain port and it will work OK.

However one scenario that breaks is if you were to speed up tests by running them concurrently. You will get random conflicts doing this unless you remember to use a different port for every test, which also increases your chances of conflicting with a port already used in the system.

Using something like this would be optional for those that need it, and I don't think it would be any harder than it is presently. For example:

HttpServer server = httpserver(0);
// ...
Content content = Request.Get("http://localhost:" + server.getLocalPort()).execute().returnContent();
assertThat(content.asString(), is("foo"));

What do you think?

from moco.

Sounds reasonable.

server.getLocalPort() only works in running block, because the port will be determined when server is started. I'm not sure whether this behaviour is acceptable.

from moco.

Seeing as it's following ServerSocket way of doing things, it could do the same thing if it's not bound yet. E.g:

Returns:
the port number to which this socket is listening or -1 if the socket is not bound yet.

Happy for you to suggest an alternative interface, though!

from moco.

The code has been committed with this issue. You can refer MocoPortTest for test cases. Any feedback is welcome.

On the other hand, Moco runner has supported this feature. The runner will pick up the port itself.

from moco.

@garrettheel , since we've already implemented this feature. What do you think if shutdown port is changed with this approach?

from moco.

@dreamhead Thanks for the implementation - it looks great. I think it would be good for shutdown port to use this approach too, as it's just one less thing to worry about and makes Moco easier to use. So long as there's a simple way to find out the port, such as server.getShutdownPort() then it should be pretty easy for me to update the maven plugin too

from moco.

@garrettheel the code has been committed. RunnerFactory will return ShutdownRunner which has shutdownPort. The latest snapshot has been uploaded to repo. Try it in your plugin.

from moco.

@dreamhead I see what you mean - this is a good idea, I'll update the plugin.

I wonder if it's also a good idea to expose the server port from a Runner so you can also have a random port when using the plugin for integration tests. The plugin could set a system property for which port Moco is running on so tests know where to send requests.

What do you think?

from moco.

One thing I am not sure about system property is when I try to run many Moco instances in one machine, all of them will set the same property.

from moco.

Fair point - by having a system property we'd be limiting one Moco instance per JVM (not per machine). Do you have any other suggestions?

from moco.