[
https://issues.apache.org/jira/browse/CAMEL-16438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312425#comment-17312425
]
David Oftedal edited comment on CAMEL-16438 at 3/31/21, 2:29 PM:
-----------------------------------------------------------------
Do the unit tests actually pass, though? If you move the properties under
"camel.component.kafka.configuration" out to "camel.component.kafka" in both
src/main/resources/application.yml and src/test/resources/application.yml , and
string-replace "camel.component.kafka.configuration" with
camel.component.kafka" in the .java files that reference the property name
directly.
What I've found in many of these cases is that moving the properties either
results in them being shown as null or some default value in the logs, or the
entire application failing to start because of the missing value.
If the properties are being set on the component, but the component still
doesn't work, then it doesn't bring us very far.
I'm away from work until the end of Easter, though, so I most likely won't have
the time to sit down with a debugger.
was (Author: davidoftedal):
Do the unit tests actually pass, though? If you move the properties under
"camel.component.kafka.configuration" out to "camel.component.kafka" in both
src/main/resources/application.yml and src/main/resources/application.yml , and
string-replace "camel.component.kafka.configuration" with
camel.component.kafka" in the .java files that reference the property name
directly.
What I've found in many of these cases is that moving the properties either
results in them being shown as null or some default value in the logs, or the
entire application failing to start because of the missing value.
If the properties are being set on the component, but the component still
doesn't work, then it doesn't bring us very far.
I'm away from work until the end of Easter, though, so I most likely won't have
the time to sit down with a debugger.
> Kafka component properties randomly end up under camel.component.kafka or
> camel.component.kafka.configuration
> -------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-16438
> URL: https://issues.apache.org/jira/browse/CAMEL-16438
> Project: Camel
> Issue Type: Bug
> Components: camel-kafka, camel-spring-boot
> Affects Versions: 3.8.0, 3.9.0
> Reporter: David Oftedal
> Priority: Minor
> Fix For: 3.10.0
>
> Attachments: kafka-chaos.zip
>
>
> According to
> [https://camel.apache.org/manual/latest/camel-3x-upgrade-guide-3_2.html#_configuring_components_via_spring_boot_auto_configuration]
> , Camel component configuration should as of version 3.2 no longer use the
> .configuration prefix.
> In version 3.8.0, many properties have indeed moved out of .configuration.
> But some properties are still only set if set with the .configuration prefix.
> The same seems to be the case in 3.9.0 as well.
> As far as I can tell, this non-exhaustive list contains valid examples:
> * camel.component.kafka.configuration.brokers (specifically mentioned in the
> documentation as having moved)
> * camel.component.kafka.configuration.max-poll-records
> * camel.component.kafka.configuration.group-id
> * camel.component.kafka.configuration.topic
> * camel.component.kafka.configuration.ssl-keystore-password
> * camel.component.kafka.configuration.ssl-truststore-password
> * camel.component.kafka.configuration.value-deserializer
> Some properties seem to have moved *to* .configuration:
> * camel.component.kafka.configuration.allow-manual-commit
> * camel.component.kafka.configuration.break-on-first-error
> Some related properties now appear to be split between two prefixes:
> * camel.component.kafka.ssl-keystore-location and
> camel.component.kafka.configuration.ssl-keystore-password
> * camel.component.kafka.ssl-truststore-location and
> camel.component.kafka.configuration.ssl-truststore-password
> * camel.component.kafka.value-serializer and
> camel.component.kafka.configuration.value-deserializer
> Trying to figure out what goes where requires a pretty exhaustive and
> error-prone search.
> Obviously it's possible to copy and paste each property so that it's set
> both with and without .configuration, but if the intent is to remove
> .configuration altogether, would it be possible to either confirm or negate
> what we're seeing?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
