oscerd opened a new pull request, #2993:
URL: https://github.com/apache/camel-kamelets/pull/2993
Fixes #2969.
Five Kamelets defaulted `avroDatumProvider` to
`io.apicurio.registry.serde.avro.ReflectAvroDatumProvider`. Apicurio's own
default is `DefaultAvroDatumProvider`, so the catalog was silently flipping a
library default rather than restating it.
Confirmed from the shipped bytecode rather than from documentation —
`AvroKafkaSerdeConfig` is the class that holds the constant:
```
AvroKafkaSerdeConfig: class
io/apicurio/registry/serde/avro/DefaultAvroDatumProvider
```
## Why it matters
On the **read** path, the reflect provider lets the schema resolved from the
registry drive reflection-based class resolution during deserialization.
Narrowing the five:
| Kamelet | reads Avro? | disclaimed by name? |
|---|---|---|
| `kafka-batch-apicurio-registry-source` | yes | **no** |
| `kafka-batch-apicurio-registry-not-secured-source` | yes | yes
(`-not-secured-`) |
| `kafka-not-secured-apicurio-registry-source` | yes | yes (`-not-secured-`)
|
| `kafka-apicurio-registry-not-secured-sink` | writes | yes |
| `kafka-not-secured-apicurio-registry-sink` | writes | yes |
`kafka-batch-apicurio-registry-source` is the only one that both reads Avro
and is not already disclaimed by a `-not-secured-` name. The sinks *write*
Avro, where reflection over the route's own outbound objects is a much weaker
concern.
I changed all five anyway — the inconsistency is not worth preserving, and
restating the library default is the same fix everywhere.
## What changed
```diff
avroDatumProvider:
title: Avro Datum Provider
- description: How to read data with Avro
+ description: How to read data with Avro. Defaults to Apicurio's own
DefaultAvroDatumProvider,
+ which handles GenericRecord and generated SpecificRecord classes.
Set
+ io.apicurio.registry.serde.avro.ReflectAvroDatumProvider to map
Avro onto arbitrary POJOs
+ by reflection instead.
type: string
- default: "io.apicurio.registry.serde.avro.ReflectAvroDatumProvider"
+ default: "io.apicurio.registry.serde.avro.DefaultAvroDatumProvider"
```
The reflect provider stays fully available — it moves from an invisible
default to an informed opt-in, with the description saying what each one
actually does.
## Compatibility — please read before merging
**This changes deserialization behaviour for existing users.** Anyone
relying on the implicit reflect provider to map Avro onto plain POJOs will find
that stops working until they set `avroDatumProvider` explicitly:
- `DefaultAvroDatumProvider` → `GenericRecord` and generated
`SpecificRecord` classes
- `ReflectAvroDatumProvider` → arbitrary POJOs via reflection
It is a one-line opt-in to restore, but it is not a silent no-op, so it
wants a release-note mention. Per the contributor guidelines a default change
like this is committer territory rather than something to wave through —
flagging it rather than burying it.
An alternative shape, if reviewers prefer the catalog to assert nothing at
all: drop `default:` entirely and switch the template placeholder to
`{{?avroDatumProvider}}`, so Apicurio's default applies and the catalog
automatically tracks it if upstream ever changes. I went with the explicit
default because it stays visible in tooling, but I am happy to switch.
## Verification
`script/validator` reports no errors, `script/generator` produces no doc
changes, and `mvn clean install` passes from the repository root. No
`ReflectAvroDatumProvider` default remains in the catalog.
The issue also asked to confirm the effective Avro version resolved via
`mvn:io.quarkus:quarkus-apicurio-registry-avro:3.24.2` — I have not done that
here; it is independent of this change and better handled on its own.
---
_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]
