[Use Case]: Inheritance of annotations beyond Jakarta interceptor bindings

[yrodiere]

As a ...

• Application user/user of the configuration itself
• API user (application developer)
• SPI user (container or runtime developer)
• Specification implementer

I need to be able to ...

... apply annotations to my repository interfaces, and have them taken into account in repository implementations even if the annotations are not CDI interceptor bindings.

Which enables me to ...

• secure access to Jakarta Data repositories according to roles/permissions defined by jakarta.security annotations
• <put the effect of any method-level annotation you can think of here>

Additional information

Section 7.2 of the spec states:

A repository interface or method of a repository interface may be annotated with an interceptor binding annotation. In the Jakarta EE environment—​or in any other environment where Jakarta Interceptors [6] is available and integrated with Jakarta CDI—​if the repository implementation is instantiated by the CDI bean container then the interceptor binding annotation is inherited by the repository implementation. That is, the interceptor binding annotation must be treated as if it were placed directly on the repository implementation bean. The interceptors bound to the annotation are applied automatically by the implementation of Jakarta Interceptors.

This is a very useful feature, but unfortunately limited to interceptor binding annotations.

There are more annotations that could be applied to repositories, and that would make sense to be "inherited" -- copied, really -- by the Jakarta Repository implementation.

One example, and I want to stress that even if it's arguable, it's just an example among others, is Jakarta Security annotations. Frameworks would likely comply with jakarta.annotation.security.RolesAllowed through some kind of interceptors, perhaps even CDI interceptors, but the annotation itself is not an interceptor binding -- it's not meta-annotated with @jakarta.interceptor.InterceptorBinding

We could say that "security annotation should be annotated with @Inherited", but we would be wrong -- from https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/annotation/Inherited.html: "this meta-annotation only causes annotations to be inherited from superclasses; annotations on implemented interfaces have no effect". So, not a good match for Jakarta Data repositories.

---

Could we extend the definition of which annotations should be copied from the interface to the implementation?
Perhaps list Jakarta Security annotations?
Maybe decide that @Inherited annotations will be copied to implementations, thereby fixing the weird "official" definition of @Inherited in the JDK?

Alternatively -- or perhaps additionally -- could you confirm that the processor may chose to copy more annotations than what's mentioned in the spec? In which case this problem could be shifted to implementations.

[njr-11]

Alternatively -- or perhaps additionally -- could you confirm that the processor may chose to copy more annotations than what's mentioned in the spec? In which case this problem could be shifted to implementations.

Implementations are always free to add their own vendor-specific behaviors as long as they don't conflict with the specification. And even if there were a conflict, an implementation is still free to add the behavior as non-default with configuration to enable it. That said, it would be better to standardize a solution in Jakarta EE then rely on vendor behavior.

The problem here is a little more complicated though. With the Jakarta Data specification as currently written, you can already use some non-interceptor annotations on repositories. Some which I've seen used include @PersistenceUnit, @Resource, and @DataSourceDefinition, which are convenient given that @Repository(dataStore=...) can point to these. They work, not because of anything Jakarta Data defines, but because the container can identify and process them from interfaces as well as other classes. The problem that comes up here if Jakarta Data were to require copying all annotations from the repository to the repository implementation, then annotations such as these will have duplicate declarations in both places,, which, depending on the annotation, might not be valid.

I think you have a good idea here, but it would need to be very precise about which annotations it applies to and which it doesn't. One way to do that, at least for the security annotation you identified, would be to request an update to the Jakarta Security specification to define that @RolesAllowed can annotate an interface class/methods, in which case it applies to implementations of the interface/methods.

[gavinking]

One way to do that, at least for the security annotation you identified, would be to request an update to the Jakarta Security specification to define that @RolesAllowed can annotate an interface class/methods, in which case it applies to implementations of the interface/methods.

I guess the real problem with the security annotations is that in principle they should be interceptor binding types, but they're not, and it's not straightforward to redefine them as interceptor binding types because the annotations module doesn't have a dependency on the interceptors module.

But, I mean, the annotations module is just completely abandoned and unmaintained as far as I can tell. If we still actually care about it, then we need a new spec lead to take over responsibility for it.

[gavinking]

Could we extend the definition of which annotations should be copied from the interface to the implementation?

The question is "how"?

We can't just say that every annotation is inherited by repository impls.

We could introduce our own @InheritedByRepositoryImplementations annotation, but then none of the annotations you're interested in would actually have this annotation, and it wouldn't be useful.

We could give the user the ability to declare that a given annotation is automatically inherited by repositories, but that's not really that nice.

So, I dunno, we need to see more concrete examples. The security annotations are a good concrete example, I think the issue there is really that those annotations should have been respecified as interceptor binding types a long time ago and it's just inertia that stands in the way of that.

[gavinking]

The security annotations are a good concrete example

We can of course list the security annotations explicitly in the spec as a special case, if people think that a repository is a sensible place to do authorization checks.