Is your feature request related to a problem? Please describe.
Add support for additional special characters in JacksonEventKey class. Currently it only supports alphanumeric as well as .-_@/.
We have a use case for preserving keys from input without any character replacement.
We have looked at the first PR of adding JacksonEvent class but cannot find any description of why character validation is so strict--if there is a requirement against special characters, it would be appreciated to help uncover the reason.
Describe the solution you'd like
Add support for marking the following characters as valid: spaces ( ), dollar signs ($). However, if possible, also add support for any ASCII punctuation/symbols, since there are likely going to be similar keys we need to translate in the future.
Describe alternatives you've considered (Optional)
Character replacement. But due to our end use case, we need to preserve the source key without modification
Additional context
Code source:
We just need to support more additional characters:
private static boolean isValidKey(final String key) {
for (int i = 0; i < key.length(); i++) {
char c = key.charAt(i);
if (!(c >= 48 && c <= 57
...
|| c == ']'
|| c == ' ' # new
|| c == '$' # new
|| c == '#' # new
|| c == '!' # new
# etc...
...
Is your feature request related to a problem? Please describe.
Add support for additional special characters in JacksonEventKey class. Currently it only supports alphanumeric as well as
.-_@/.We have a use case for preserving keys from input without any character replacement.
We have looked at the first PR of adding JacksonEvent class but cannot find any description of why character validation is so strict--if there is a requirement against special characters, it would be appreciated to help uncover the reason.
Describe the solution you'd like
Add support for marking the following characters as valid: spaces (
), dollar signs ($). However, if possible, also add support for any ASCII punctuation/symbols, since there are likely going to be similar keys we need to translate in the future.Describe alternatives you've considered (Optional)
Character replacement. But due to our end use case, we need to preserve the source key without modification
Additional context
Code source:
We just need to support more additional characters: