An idea I had is to modify the API and use a setter that would require both the name and the display name. That way and you deprecate the other two over time.
Example: setName(String name, String DisplayName) This would require both values to be filled out, and since it's overloaded you could introduce non intrusively. I understand this might not fit with the Java builder pattern best practice. On Tue, May 3, 2016 at 12:09 PM, Andy LoPresto <alopre...@apache.org> wrote: > As a result of some conversations and some varying feedback on PRs, I’d like > to discuss with the community an issue I see with PropertyDescriptor name > and displayName attributes. I’ll describe the scenarios that cause issues > and my proposed solution, and then solicit responses and other perspectives. Andy, I'd be +1 on this as well. I think the power of this approach will become more clear over time, and some of the automation will make it possible to more widely enforce. What do you think about a mixed mode where config reading code can fetch the property value with either the name or display name as the key, defaulting to the name if it is present? A sample read of flow.xml.gz might look like this: * Processor asks for value of MY_CONFIG_PROPERTY * Configuration code looks for key "my-config-property", returns if present * Configuration code looks for key "My Config Property", returns if present * On finding no valid key, configuration returns blank/default/null value (whatever is done today) On configuration write, the new attributes could be written as the normalized name (instead of display name), to allow processors that have made the switch to start using the normalized name field and start taking advantage of the new features around it (e.g. internationalization). Perhaps a disadvantage to this approach is that it auto-upgrades an existing flow.xml.gz, making it difficult to downgrade from (for example) 0.7 back to 0.6. A strategy like this (or something similar) might help speed adoption by making the process a bit smoother for existing flow.xml.gz files and easier to upgrade processors incrementally. At 1.0, display names as configuration keys could be dropped, and the upgrade path for users on old 0.x releases would be to upgrade to the latest 0.x before making the jump to 1.0. Cheers, Adam
