Create Annotation for constructor parameter names and ParameterNameDiscoverer to understand it

Description

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 be

class 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.

Environment

Lets try get some more of this done in V3.4 and nail it properly (as much as is possible) in V4

Activity

Show:

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

Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Original estimate

Components

Fix versions

Affects versions

Created September 17, 2016 at 1:42 PM
Updated January 18, 2023 at 1:26 PM
Resolved November 21, 2020 at 4:28 PM