[clarification]: should we require an annotation for resource accessor methods

[gavinking]

Specification

resource accessor methods

I need clarification on ...

We had a discussion recently around how to test resource accessor methods in the TCK.

Some level of testing would be possible if, instead of relying on the return type to identify a resource accessor method, we introduced an annotation, say @Accesses or @BackedBy or something like that. Then the TCK could declare a method with signature:

@Accesses Object resource();

and test that it doesn't return null. That's some sort of a test at least.

In practice, users would declare their repository with:

@Accesses EntityManager resource();

or whatever. This is a bit more explicit, and only slightly more verbose.

I dunno, I'm far from convinced this is objectively better, but I thought I should throw it out there as an option.

It's just a suggestion. If no-one speaks up enthusiastically in favor of this, I will just close the issue.

Additional information

No response

[njr-11]

Some level of testing would be possible if, instead of relying on the return type to identify a resource accessor method, we introduced an annotation, say @Accesses or @BackedBy or something like that. Then the TCK could declare a method with signature:

@Accesses Object resource();

and test that it doesn't return null. That's some sort of a test at least.

The test is only possible for this because it uses a return type of Object and assumes/requires that a provider make exactly one type of resource accessible. It seems like an anti-pattern for a user to specify a return type of Object when they know the type they really want and will need to cast.

Instead, if one of the built-in repositories (DataRepository or BasicRepository) had a method like,

    <R> Optional<R> getResource();

then the user could avoid the cast, and there would be a natural place (in the method JavaDoc) for the user to discover the availability of resource accessor methods and how to use them.

The TCK could then try out the 3 types that are mentioned in the spec (EntityManager, DataSource, and Connection) and assert that the optional is either empty (meaning the type is not available) or a value is returned that can then be used to perform some minor operation.