Kafka ser/deser auto-detection bug during hot-reload

[FroMage]

Describe the bug

There's a bug with hot-reload and https://quarkus.io/guides/kafka#serialization-autodetection

public class OrderSerializer extends ObjectMapperSerializer<Order> {
    public OrderSerializer() {
        super();
    }
}

How to Reproduce?

• git clone https://github.com/FroMage/devoxx-fr-2021-quarkus-cheese-shop
• cd devoxx-fr-2021-quarkus-cheese-shop
• Edit the OrderSerializer.java file to the incorrect:

// Incorrectly a Deserialiser as pasted from the guide
public class OrderSerializer extends ObjectMapperDeserializer<Order> {
    public OrderSerializer() {
        super(Order.class);
    }
}

• quarkus dev
• Go to http://localhost:8080/order
• It fails, fine
• Edit the OrderSerializer.java file to fix it:

public class OrderSerializer extends ObjectMapperSerializer<Order> {
    public OrderSerializer() {
        super();
    }
}

• Go to http://localhost:8080/order
• Should work, but doesn't

[quarkus-bot]

/cc @cescoffier, @ozangunalp

[Ladicek]

@ozangunalp just FYI, I'm looking at this, see the Zulip conversation :-)

[ozangunalp]

@Ladicek Thanks for the heads up, I was going to ping you anyways

[Ladicek]

So I was able to trace this down to what seems like a classloading issue, or maybe bootstrap issue, I don't really know.

What I do know is that during hot reload, the io.quarkus.runtime.generated.Config class, which -- among others -- defines the "runtime defaults" config source, is regenerated correctly. As in, the static initializer of the class correctly creates the HashMap with all the right config keys/values, and passes it to the PropertiesConfigSource constructor, together with the string "Specified default values".

However, even after hot reload, the PropertiesConfigSource (specifically the one that's named Specified default values) instance used during configuration lookup didn't change. It's the same instance as before hot reload.

I placed a breakpoint into QuarkusConfigFactory#setConfig and inspected the class of the parameter (SmallRyeConfig), as well as the class of the this object one stack frame up (which is always io.quarkus.runtime.generated.Config, because I'm ignoring the config stuff during augmentation). They always come from the same classloader: QuarkusClassLoader:Quarkus Base Runtime ClassLoader: DEV@63e02bfa.

To me, this means that even though the Config class is regenerated correctly, that regenerated version is never picked up. The base classloader is AFAIR one that is reused across restarts. It seems that io/quarkus/runtime/generated/Config.class is present in the resettableElement element of the classloader, and I can see QuarkusClassLoader#reset being called (and io/quarkus/runtime/generated/Config.class is present in the generatedResources map), but that doesn't seem to make a difference.

CC @stuartwdouglas, as this is clearly way above my paygrade 😆

[stuartwdouglas]

This is a duplicate of #17069