Query method parameter of type Class erroneously considered dynamic projection parameter

[odrotbohm]

Consider a repository query method declaration like this:

interface SomeRepository extends Repository<SomeAggregate, …> {

  @Query("some query using `type` as parameter")
  <T extends SomeAggregate> Collection<T> findOnlySpecificSubTypes(Class<T> type);
}

The query method intends to find only subtypes of SomeAggregate and the type being defined by the type parameter. Unfortunately, it is currently always considered a dynamic projection parameter, even if we are not dealing with a projection here.

The decision whether a parameter is considered a dynamic projection one is currently held in Parameter which as of now, unfortunately, doesn't know anything about the primary aggregate type. If it had that, we could back out of any projection considerations once we realize the Class' component type is tied to that.

A different approach could be to disregard a Class parameter annotated with @Param as projection parameter. The annotation currently requires a value to be set, which makes it a bit cumbersome to use, as you'd need to repeat the parameter name unconditionally. I am not sure whether making that optional would be a big issue.

[odrotbohm]

After a brief discussion with @mp911de we decided it would be feasible to hand the aggregate type into the creation call chain of the Parameters instances. We can implement this in a backwards-compatible way so that we wouldn't break store modules but get them onto the new API eventually. A spike incorporating Commons and JPA seems to validate the feasibility.

The support for @Param could be added as a mitigating measure and less invasive fix for the 2.x branch, with a deprecation of that support added in 3.1.