Clarify class-level interceptor binding inheritance

[Ladicek]

Description

The Java language and the CDI specification (following Common Annotations) both define that class-level annotations are inherited only if they are @Inherited. By default, ArC inherits class-level annotations even if they are not @Inherited, which is confusing and wrong.

Unfortunately, it is also what Quarkus security expects -- because it uses annotations such as @RolesAllowed as [inheritable] interceptor bindings. In #33523, we fixed this in ArC strict mode, but by default, non-@Inherited annotations are still inherited.

Implementation ideas

One option is to fix inheritance of interceptor bindings for good and use annotation transformations to make the security annotations @Inherited.

[Ladicek]

CC @mkouba @manovotn @sberyozkin

[manovotn]

...because it uses annotations such as @RolesAllowed as [inheritable] interceptor bindings.

Is there an actual reason why these annotations aren't @Inherited?
Or a use case where that would be undesirable?

One option is to fix inheritance of interceptor bindings for good and use annotation transformations to make the security annotations @inherited.

If we can transform those annotations directly, that would be the smoothest solution so +1

[manovotn]

Looking back at this, we never took any action.

One option is to fix inheritance of interceptor bindings for good and use annotation transformations to make the security annotations @inherited.

@Ladicek did you mean to transform all of bindings in the app or just the security related ones?
CDI generally recommends having interceptor bindings marked as @Inherited and TBF I find it hard to imagine a scenario in which you'd need to not have it inherited.

[Ladicek]

No, I meant just the security ones. They are not annotated @InterceptorBinding and I'm not sure they were meant to be interceptor bindings, hence they are not @Inherited. Yet we treat them as such.

[manovotn]

Fair enough, I'll take a look into that