[ https://issues.redhat.com/browse/IPROTO-162?page=com.atlassian.jira.plugi... ] Nistor Adrian updated IPROTO-162: --------------------------------- Description: 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. 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 WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting. The only way to work around the data compat issue is to change your java classes do as not to use nesting and basically with the end result of the schema being generated exactly as before the fix.   was: Message types generated with annotation processing during compile time should follow the nesting of the classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types becoming top level types in the generated schema.   Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite. -- This message was sent by Atlassian Jira (v7.13.8#713008)