org.springframework.boot.testsupport.container.ArtemisContainer cannot be configured

[snicoll]

I am trying to use the new ArtemisContainer with some customizations:

static final ArtemisContainer container = TestImage.container(ArtemisContainer.class)
		.withEnv("EXTRA_ARGS", "--queues %s:anycast".formatted(QUEUE_NAME));

That doesn't work because org.springframework.boot.testsupport.container.ArtemisContainer extends org.testcontainers.activemq.ArtemisContainer but none of the builder-style method do return the sub-class.

This works:

@Container
@ServiceConnection
static final org.testcontainers.activemq.ArtemisContainer container = TestImage.container(ArtemisContainer.class)
	.withEnv("EXTRA_ARGS", "--queues %s:anycast".formatted(QUEUE_NAME));

[snicoll]

I'd like someone to double check but it looks like the empty classes we have are just there as a signal for the Enum to match the call to forContainerClass. I've hacked a simple method on TestImage:

@SuppressWarnings("unchecked")
public <C extends Container<?>> C customize(Consumer<C> containerSetup) {
	C container = createContainer((Class<C>) this.containerClass);
	containerSetup.accept(container);
	return container;
}

With that in place, my setup code looks as follows:

@Container
@ServiceConnection
static final ArtemisContainer container = TestImage.ARTEMIS.customize((c) ->
		c.withEnv("EXTRA_ARGS", "--queues %s:anycast".formatted(QUEUE_NAME)));

I wonder if that could be a replacement where you'd be explicit using the enum, rather than passing the name of the container that would magically find the actual image you want to use. The cast is unpleasant but I don't see how else we could handle this. Perhaps TestImage should not be an enum?

[snicoll]

So we need an enum for the docker compose support that needs one for its annotation. I suppose we could reverse the problem by having something that can parse from the enum. However, we're a bit stuck as we want to expose a type with a generic to be able to offer the type of container to customize.

Given the limitations, I wonder if the above wouldn't be so bad.

[kush2439p]

I'd like to try fixing this if that's okay. My initial thought is to override the fluent builder methods in the Spring Boot ArtemisContainer subclass (returning this typed as the subclass) similar to how other testcontainers wrappers handle it here — does that sound like the right direction, or did you have something else in mind?

[snicoll]

No, I don't think I'd like to fix that at the container level. This is flagged for team attention, which means we need more feedback before taking any direction. Thanks for the offer, in any case.

[snicoll]

I've tried something that would not force us to create "fake" containers to have an additional entry. I am not quite sure it's right, especially with the casting: https://github.com/snicoll/spring-boot/tree/gh-51082