oscerd opened a new issue, #2969:
URL: https://github.com/apache/camel-kamelets/issues/2969
Five Kamelets declare `avroDatumProvider` with a default of
`io.apicurio.registry.serde.avro.ReflectAvroDatumProvider`:
- `kafka-batch-apicurio-registry-source`
- `kafka-batch-apicurio-registry-not-secured-source`
- `kafka-not-secured-apicurio-registry-source`
- `kafka-apicurio-registry-not-secured-sink`
- `kafka-not-secured-apicurio-registry-sink`
Apicurio's own default is `DefaultAvroDatumProvider`. Confirmed from the
bytecode of `apicurio-registry-serdes-avro-serde`:
```
public static final java.lang.String AVRO_DATUM_PROVIDER_DEFAULT;
Code:
0: ldc #87 // class
io/apicurio/registry/serde/avro/DefaultAvroDatumProvider
```
So the Kamelets flip a library default rather than restating it. With the
reflect provider, the schema resolved from the registry drives reflection-based
class resolution during read.
Narrowing which of the five actually matter:
- The two **sinks** *write* Avro. Reflection over the route's own outbound
objects is a different and much weaker concern.
- Three are **sources**, but two of those carry `-not-secured-` in the name,
which the catalog treats as a documented development/test posture.
That leaves exactly one Kamelet that both reads Avro and is not disclaimed
by its name: **`kafka-batch-apicurio-registry-source`**.
Proposal: default all five to `DefaultAvroDatumProvider` and keep
`ReflectAvroDatumProvider` as a documented opt-in. Prioritise
`kafka-batch-apicurio-registry-source`.
Worth confirming the effective Avro version resolved via
`mvn:io.quarkus:quarkus-apicurio-registry-avro:3.24.2` while this is being
looked at.
_Claude Code on behalf of Andrea Cosentino_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
