During testing I found out, that my deserializer of avro messages fails for some testing schema. It was completely puzzling to me for a long time. So my avro deserializer deserializes someNameSpace.someType class, stored in GenericRecord return value. Then it gets casted to [same] someNameSpace.someType, and it failed. Why? Trivially because of different classloader.
But why just this test schema? I learned, that all locally present files, will be loaded by this classloader. Ok, I woulndn't be surprised by that for some resources, but here the situation was a little bit different.
Maven-avro-plugin took avsc file, compiled java file out of it in generate-sources phase. Then this file gets compiled to .class file, and deserializer gets initialized via avsc file. So far so good. Then new message arrives. It get deserialized by appClassLoader, while casting from GenericRecord to actual class, which is done by standard cast (someNameSpace.someType) fails, because of someNameSpace.someType was loaded by restart class loader. Very surprisingly the avsc resource read using PathMatchingResourcePatternResolver (≈Class.getResourceAsStream) is loaded by AppClassLoader, while the class file built from that is loaded using restart class loader.
Questions: a) is spring restart class loader supposed to load class files? b) I did not find if someone can exclude certain class files from being processed by this class loader. I found how-to for resources, but not for class files... c) did anyone encounter this behavior? Is it just misconfiguration on my side of some sort, or what did you do tackle this (well except of removing spring-boot-devtools)
idea version: 193.5662.53 spring version: 2.0.4
Thanks!
