Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared.

Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite and not the compile time variant so it flew under the radar. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes.

Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing.

The fix will have the important side effect of breaking the compatibility of data stored as a WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting (but please note the structure of messages does not change!). These usages are not affected if the message types in question have a TypeId annotation, in which case WrappedMessage identifies the type base on its numeric id rather than its fully qualified name.

The only way to work around the data compat issue is to change your java classes so as not to use nesting with the end result of the schema being generated exactly as before this bug fix (all types are top level).