Kafka Interceptor - configuration from @QuarkusTest

[muirandy]

Hi

I have a reasonably simple Kafka interceptor - a pojo implementation of ProducerInterceptor<K,V>. Its job will be to send a message to another application over HTTP. However, the interceptor needs to know where the listening application is - hostname and port.

This can be configured through the application.properties file, eg:
mp.messaging.<name>.responses.interceptor.myHostName=localhost
mp.messaging.<name>.responses.interceptor.myPort=9001
The properties get passed in to the interceptor through the public void configure(Map<String, ?> map) method.

However, when my @QuarkusTest starts up, it uses a QuarkusTestResourceLifecycleManager to start-up a docker container - this will be the app listening. Whilst this is still on localhost, it is on a dynamic port.

Any ideas how I can configure things so that the Kafka interceptor can get hold of that?! I can wire in the values from the QuarkusTestResourceLifecycleManager into the QuarkusTest, but how can I set an ENV VAR or property so the interceptor can get it?

[quarkus-bot[bot]]

/cc @alesj (kafka), @cescoffier (kafka), @ozangunalp (kafka)

[alesj]

I guess QuarkusTestResourceLifecycleManager::start properties end up in app's properties,
but they are not the right one's to be passed to your Kafka (interceptor) config?

What if you grab an instance of Config (ConfigProvider::getConfig) in your interceptor and get that property that QTRLM previously provided, that holds the newly occupied Kafka port ...

[muirandy]

Hi @alesj - thanks for your suggestion!

The QuarkusTestResourceLifecycleManager::start properties end up in the test ok, and they do have the values I'm after, however the interceptor is in a separate JAR and has no concept of Quarkus. That puts ConfigProvider::getConfig out of bounds of the interceptor itself.

[alesj]

What if you add your own ConfigSource -- via services/ -- which is after the ConfigSource which gathers QTRLM::start props ...,
and your CS provides the right property -- re-mapping the one from QTRLM ... just thinking out-loud ... (dunno if this will work)

@geoand @cescoffier @stuartwdouglas ... any other idea?

[geoand]

If the interceptor is part of library that has no knowledge of Quarkus, I would propose providing an SPI that would implemented on the Quarkus application in order to pull properties from Quarkus and make them available to the library