-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce a BuildItem in DevKafkaService to add additional config #25140
Conversation
…dditional configs
Thanks for your pull request! The title of your pull request does not follow our editorial rules. Could you have a look?
|
...ent/src/main/java/io/quarkus/kafka/client/deployment/DevServiceKafkaAdditionalBuildItem.java
Show resolved
Hide resolved
HashMap<String, String> configs = new HashMap<>(); | ||
configs.put(KAFKA_BOOTSTRAP_SERVERS, address); | ||
additions.forEach(c -> { | ||
configs.put(c.getConfig(), address); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The BuildItem
is used exclusively to set the Kafka's server address as a value for other keys?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, we use it in camel.component.kafka.brokers
see apache/camel-quarkus#3742
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also you can check the detail about the motivation of these changes in #25094
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, I am just concerned that the class name DevServiceKafkaAdditionalBuildItem
may be too generic for this reason
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, it is hard to name it :) any thought ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that this is the right solution for this problem.
We need to understand why DevServicesLauncherConfigResultBuildItem
doesn't contain the dev service config in native mode.
The code here seems to be the right way of getting the dev service config.
But in camel-quarkus-kafka, the above build step seems not run at all in native mode. I'm not sure it is because we produce |
@zhfeng In integration tests, the application is built in "normal" mode, without dev services or test mode augmentation. That's why contrary to what I wrote before, the previous code is not the right way of doing this. In hindsight, I don't completely understand the need to have a Maybe @geoand would have another take on this? Ref #25094 |
I don't undertand this requirement at all either :) @zhfeng can you describe the end goal of what you are trying to do? |
@ozangunalp camel-quarkus-kafka extension reads @gastaldi I want to get the %prod.camel.component.kafka.brokers=${kafka.bootstrap.servers} @jamesnetherton do you have any input here? |
@ozangunalp I find some similar codes with HibernateOrmProcessor.java which produce So I wonder this is only availiable in JVM but not Native testing? |
Same for hibernate, that runtime default config would not be set on the application under test during integration tests. |
Thanks for explanation. So I think it could be much more reasonable to introduce such a BuilidItem in DevServiceKafka which could be very helpful for other extensions in IT native testing. |
I couldn't find where does the |
yeah, we have an example https://github.com/apache/camel-quarkus-examples/tree/main/kafka. We only want Since the native IT test is running in |
Shouldn't this be done by the camel extension? As highlighted before, having
is the right way to do it Today. |
Thanks @cescoffier ! As I understand, the purpose of dev services is avoiding or lessing the configurations when running the tests. That was the motivation we did in camel-quarkus-kafka extension before. So I think it is only possible to achieve this target both in JVM and Native mode by introducing a BuildItem to produce an additional configuration. |
@zhfeng I do not follow. First, dev services are not about reducing the configuration, but about running infrastructure services automatically. |
@cescoffier yeah, we can define the property but |
This property is set by the dev service, but is used every time. So in prod mode, the user would have to set it (or use SBO). |
Sorry, what is |
Service Binding Operator |
Thanks all for reviewing. I'd like to close this PR and follow @cescoffier recommendation to set the property in prod mode. |
Fix #25094