Project: springxd
Issue XD-953: Richer module options metadata
Module options are currently implemented using PropertySourcesPlaceholderConfigurer, doing simple "text" replacements. This story proposes to introduce a richer model for module options, which could take the following xml representation (keeping in mind that there would be an underlying set of classes that could also apply to e.g. @Configuration approach): {code:xml} {code} So, the very first obvious benefit is providing help metadata. The second one is an easy way to list available option names, without resorting to brittle PropertySourcesPlaceholderConfigurer hacks (we wouldn't for example detect xd.stream.name or XD_TRANSPORT as a valid option) One could also specify defaults/computations, this time benefiting from SpEL everywhere: {code:xml} {code} Lastly, this opens the door to better type checking / combinations / optionality support: {code:xml} {code} The 'valid' attribute can e.g. be evaluated by SpEL. Some final remarks: - That construct can be compatible with our current approach by behaving as a PropertySource itself (instead of creating a PropertySource, the StreamPlugin would give this new bean the java.util.Properties) - Plugins could benefit from a hook in that construct and advertise the fact that they expect/provide new options (e.g. --inputType) There is a slight problem though, which is that if this construct lives in the same AppContext as the module definition itself, then the AppContext needs to be refreshed for the logic to kick in. One could circumvent that using profiles, or we could rely on a different filename convention (e.g. -params.xml)
Story points: 10