Issue #361: Add Support for Resolving Property Values

[jghiloni]

Add Support for Resolving Property Values in @RequestMapping(value)

Creates extra methods in AnnotationMappingDiscoverer, ControllerLinkBuilder, and ControllerLinkBuilderFactory to take an Environment object that can be used resolve placeholders. Accepts null Environments to allow for backward compatibility.

[jhoeller]

Could use PropertyResolver instead of Environment, or even a plain StringValueResolver that could be adapted from a PropertyResolver (see PropertySourcesPlaceholderConfigurer's implementation).

[jghiloni]

I like the idea, but I'm unclear as to where the StringValueResolver would get the values to use for substitution. Are you suggesting passing that in instead of an Environment, or somehow having the resolver as an instance variable?

[jhoeller]

Indeed, a StringValueResolver would have to be adapted from a PropertyResolver along the lines of PropertySourcesPlaceholderConfigurer, line 170+, so it's not really convenient to use for that purpose. Declaring PropertyResolver itself in such a signature might be the better choice, since Environment implements PropertyResolver and can therefore be passed in directly.

[jghiloni]

That's a good point. I'll make the necessary changes to reflect that (Passing PropertyResolver instead of Environment)

[jghiloni]

Any news on this?

[gregturn]

@jghiloni Ollie has been on PTO since SpringOne so things may be slow in coming out right now.

[jghiloni]

Ah, makes sense! No real rush, just noticed it was still open.

[odrotbohm]

I don't like that now the ControllerLinkBuilder is now scattered with PropertyResolver parameters, something as it really breaks the abstraction (why would a client have to know about property resolution when calling those methods).

Maybe we can move the changes to the ControllerLinkBuilderFactory, which is an instance based alternative to the static ControllerLinkBuilder, which then can take an Environment as configuration setup to then use it during link resolution without polluting the parameter space?

[gregturn]

Catching up on @olivergierke 's comments on this feature. I'll try to see how this now operational PR can be retooled to not percolate this change into so many APIs.

[gregturn]

The related branch now shows a different solution that doesn't require altering any method signatures. It's also more composable.