Heads up: Avro 1.12.2 breaks reflection-based sche...
# dev
l
Heads up: Avro 1.12.2 breaks reflection-based schemas ⚠️ Upgrading Avro 1.12.0 → 1.12.2 github.com/apache/pulsar/pull/24992 affects user applications on upgrade, not just our own code. • What changed — the change landed in 1.12.2 rather than 1.12.1 (AVRO-4189): Avro now refuses to reflect over any class that isn't explicitly trusted, on every reflective class resolution. • What breaks —
Schema.AVRO(MyPojo.class)
throws
SecurityException
on produce and consume.
Schema.JSON
is not affected. • Handled for you — broker types, plus Pulsar Functions and IO connectors, which trust the deployed code's class loader. • Applications declare their own POJOs —
AvroTrustedClasses.trust(Order.class)
, which also covers what the class references. • ⚠️ Avro's own error message misleads shaded-client users — the property and class it names are relocated in
pulsar-client
/
pulsar-client-all
, so following it produces an identical failure. Full details on dev@: lists.apache.org/thread/…
Most likely there are unpublished CVEs which are fixed by 1.12.2 so we will have to handle the upgrade very soon to address those CVEs.
Update: the Avro 1.12.2 upgrade no longer requires application changes ✅ Following the discussion with Matteo, the goal became making github.com/apache/pulsar/pull/24992 as non-invasive as possible for Pulsar users. That turned out to be achievable, so the earlier guidance about declaring your POJOs no longer applies. • Existing client code does not have to change — when you pass a class to
Schema.AVRO(...)
or
Schema.PROTOBUF(...)
, Pulsar already derives the schema from that class, so it can trust exactly the types that schema uses. • Same for Functions, connectors and the broker — they go through the same calls, so nothing special is needed for them either. •
Schema.AUTO_CONSUME()
is unaffected
in the normal case — it decodes into
GenericRecord
without loading your classes at all. • One narrow gap remains — a topic whose schema isn't a record at the top level. That shape is unusual, so the risk of breaking an existing application is minor. Details on dev@: lists.apache.org/thread/…