jamesfredley commented on issue #16123:
URL: https://github.com/apache/grails-core/issues/16123#issuecomment-5243108275
### Runtime confirmation for `Stampable`
The `Stampable` entry in my scan above was static analysis, so I verified it
empirically. It reproduces, and it does so **without any Spring context** -
plain compilation plus reflection is enough.
Setup: stock `grails create-app --profile=web` on the published 8.0.0-M5
distribution, with only
```groovy
implementation "org.grails.plugins:audit-logging:6.0.0"
```
and a single class applying the plugin's public trait exactly as the plugin
documents:
```groovy
package stampable
import grails.plugins.orm.auditable.Stampable
class StampedRecord implements Stampable<StampedRecord> {
String name
}
```
A plain unit test (`src/test`, no `@Integration`, no application context):
```groovy
class StampableTraitSpec extends Specification {
void 'reports the generic interfaces declared by the Stampable
implementor'() {
when:
def interfaces = StampedRecord.genericInterfaces
then:
interfaces != null
}
void 'bean introspection of a Stampable implementor succeeds'() {
when:
Introspector.getBeanInfo(StampedRecord)
then:
noExceptionThrown()
}
}
```
Both fail:
```
StampableTraitSpec > reports the generic interfaces declared by the
Stampable implementor FAILED
java.lang.reflect.MalformedParameterizedTypeException at
StampableTraitSpec.groovy:11
StampableTraitSpec > bean introspection of a Stampable implementor succeeds
FAILED
Caused by: java.lang.reflect.MalformedParameterizedTypeException at
StampableTraitSpec.groovy:20
2 tests completed, 2 failed
```
with the same message shape as `LogicalDelete`:
```
java.lang.reflect.MalformedParameterizedTypeException: Mismatch of count of
formal and actual type arguments
in constructor of
grails.plugins.orm.auditable.Stampable$Trait$FieldHelper: 0 formal argument(s)
1 actual argument(s)
at java.base/java.lang.Class.getGenericInterfaces(Class.java:1298)
at
java.desktop/com.sun.beans.TypeResolver.prepare(TypeResolver.java:312)
at
java.desktop/java.beans.Introspector.getTargetMethodInfo(Introspector.java:1030)
at
java.desktop/java.beans.Introspector.getBeanInfo(Introspector.java:446)
```
And `javap` on the Grails 8 compiled class shows the invalid signature being
emitted, the type argument on a `FieldHelper` that has none:
```
public class stampable.StampedRecord
implements grails.plugins.orm.auditable.Stampable<stampable.StampedRecord>,
grails.plugins.orm.auditable.Stampable$Trait$FieldHelper<stampable.StampedRecord>,
org.grails.datastore.mapping.dirty.checking.DirtyCheckable$Trait$FieldHelper,
org.grails.datastore.gorm.GormValidateable$Trait$FieldHelper,
groovy.lang.GroovyObject
```
Again note the contrast within one signature: the Grails 8 compiled
`DirtyCheckable$Trait$FieldHelper` and `GormValidateable$Trait$FieldHelper`
appear correctly without type arguments.
### Why this raises the severity
- It needs **no Spring context, no GORM session, and no running
application** - merely compiling a class against the trait and reflecting over
it is enough. Anything doing bean introspection (JavaBeans, Spring, Jackson,
many serializers) will hit it.
- `Stampable` is applied by application authors to **their own domain
classes**, so the blast radius is the user's code rather than a single plugin
internal.
- It is currently invisible: `audit-logging:6.0.0` fails earlier during
`doWithSpring` for the unrelated `Holders` timing reason in #16101. Fixing
#16101 alone will not make the plugin usable - this surfaces immediately
afterwards.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
