Create Annotation for constructor parameter names and ParameterNameDiscoverer to understand it
Description
Environment
Lets try get some more of this done in V3.4 and nail it properly (as much as is possible) in V4
Activity
Rod Widdowson November 21, 2020 at 4:28 PM
If anything was left to be done it would have been done
Rod Widdowson December 6, 2019 at 3:49 PM
Ongoing
Rod Widdowson October 18, 2018 at 8:01 AM
My understanding is that in Java 8 and beyond you can arrange for parameter names to be encorporated into the compiled byte stream. I hope that someone can confirm
The suggestion there fore for V4 is to use this and to only use the annotation where the names differ. Keeping the annotation does however help us remember that parameter names are an api
Rod Widdowson May 8, 2018 at 3:10 PM
All warnings generated by the test bed (except for test files) have been removed and a few other other as well.
Done for 3.4
Rod Widdowson May 8, 2018 at 9:24 AM
The resolution on Friday was
The annotation supercedes any constructor names, it is not just a warning.
The Warning (at Debug) will provide us with the low hanging fruit for V3.4 work
See http://shibboleth.net/pipermail/dev/2016-September/008570.html
This is a cross project work item, starting in Java-support with an implementation in Spring-extensions and then a scattering of annotations across the entire stack.
The problem is that given
we have made 'paramtre' part of the external API, becaause someone might have said c:paramtre="foo" in a bean file.
If someone comes along and fixes the spelling thjen the bean file will stop working.
The idea is to add an annotation (so that we know not to change it), but the geneous bit (thanks ) is that if we implement a
org.springframework.core.ParameterNameDiscoverer
and inject it suitably we can automate the process, so ion the above example it would beclass wibble {
public wibble(@ParameterName(name="parameter" Object renamed) {...}
}
The parameter name is removed from the public contract (whilst the ParameterName becomes part of it).
If this class inherited correctly we should be able to fall through into the default behavior - it would be nice to warn if we did do this for one of our classes.
Of course the problem then becomes of what to annotate, I think we need to annotate every constructor with parameters in the api trees of the IdP. OpenSAML is harder since (AIUI) the api-impl split isn't nearly as clean. I'll be asking for Brent's help there.