Make port numbers protected (now private)

[jimisola]

I'm trying to contribute to Arconia and noticed that the port number in the different Container classes are private.

E.g. for RabbitMQContainer

private static final int DEFAULT_AMQP_PORT = 5672;

private static final int DEFAULT_AMQPS_PORT = 5671;

private static final int DEFAULT_HTTPS_PORT = 15671;

private static final int DEFAULT_HTTP_PORT = 15672;

This causes some duplication of code when such as class is extended and the subclass has the add those constants again.

Would it be possible to be a bit more lenient with the access and change it to protected?

[rameshreddy-adutla]

The reason port fields in modules like PostgreSQLContainer are static final rather than protected is mainly a design trade-off:

1. Container ports are constants — they represent the fixed default port that the containerised service listens on inside the container (e.g., 5432 for PostgreSQL). They're not meant to be overridden per-instance since getMappedPort() handles the actual host port mapping at runtime.

2. If you need a custom port, you can use withExposedPorts() or withFixedExposedPort() (from the FixedHostPortGenericContainer module) to control port binding.

For the Arconia use case, if you need to extend a module and reference the port:

public class CustomPostgresContainer extends PostgreSQLContainer<CustomPostgresContainer> {
    private static final int CUSTOM_PORT = 5432;
    
    public CustomPostgresContainer() {
        super();
        addExposedPort(CUSTOM_PORT);
    }
}

Alternatively, you could open a PR to add protected getter methods (e.g., getDefaultPort()) to the base modules — that would be a backward-compatible change that the maintainers might accept. Worth filing an issue to discuss!

[ThomasVitale]

Thanks so much for your answer!

The use case would be to be able to define a fixed exposed port, for example, for PostgreSQL. As far as I can tell, the only way to define a fixed exposed port is extending the given container class (e.g. PostgreSQLContainer), override the configure() method, and inside that call addFixedExposedPort(). Since addFixedExposedPort() is protected, there's no way to pass a value without subclassing (and there's no withFixedExposedPort() method).

As @jimisola shared, it would be useful to have the default constant port number available to be used when calling addFixedExposedPort() instead of redeclaring the same constants in the subclass. Some modules like PostgreSQL (here) and MySQL (here) define the default port number as a public constant. Other modules like Artemis (here) and Oracle (here) define the default port number as a package-private or private constant. Would it make sense to align all modules and have the port number constant public, or at least protected?

As a side note: I had a look at FixedHostPortGenericContainer, but I can see it's deprecated and I'm not sure it can be used with modules like PostgreSQLContainer.

[rameshreddy-adutla]

placeholder

[jimisola]

I was a bit unclear. I meant that the constants are now private but they should be protected so that classes inheriting can access them.

[Fmarzochi]

It seems there’s a clear consensus that the current inconsistency across modules (where some ports are public and others are private) creates friction for developers extending these classes.

Aligning these constants to public static final or at least protected static final would be the best approach for a few reasons:

Dry Principle: It prevents developers from having to redeclare standard ports (like 5672 or 5432) in their subclasses, reducing hardcoded magic numbers.

API Consistency: As @ThomasVitale pointed out, modules like PostgreSQL already expose these as public. Standardizing this across Oracle, Artemis, and others makes the library more predictable.

Refactoring Safety: If a default port ever needs to change in a future version of a container image, users who reference the constant will get the update automatically, whereas those who hardcoded the value will face silent failures.

A good middle ground would be providing protected getters (e.g., getDefaultPort()) if we want to keep the fields encapsulated, but since these are industry-standard constants, making the static final fields public or protected is a very common and safe pattern in Testcontainers.

Would the maintainers be open to a PR that standardizes these access modifiers across all container modules?