Skip to content

Add possibility to escape property placeholders #30671

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

bdshadow
Copy link
Contributor

This commit allows to escape property placeholders to later processed by user. PropertyPlaceholderHelper allows to set custom escape character. "" is used as the default one.

Closes gh-9628

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jun 14, 2023
@snicoll snicoll self-assigned this Oct 8, 2023
@sbrannen sbrannen added the in: core Issues in core modules (aop, beans, core, context, expression) label Oct 8, 2023
@snicoll
Copy link
Member

snicoll commented Oct 9, 2023

Thanks for the PR. I've played with the code a bit and already polished quite a bit so I'll probably cherry-pick if you have time to update it. That doesn't work for default value having a property placeholder in it, something like:

${my.prop:\\${my.fallback}}

if my.prop isn't available, it's trying to resolve my.fallback rather than using ${my.fallback} as default value. Would you have time to add more tests and fix this? Please do so in a separate commit as I'll integrate that in what I've already polished.

@bdshadow
Copy link
Contributor Author

@snicoll yes, i will fix it
thank you for the review

@snicoll
Copy link
Member

snicoll commented Oct 10, 2023

One thing I had in mind would be to have a data structure that represents a bit of text and some extra information. You could then handle those cases:

  • It's just text and you output as is
  • It's a placeholder and it needs to be resolved

Perhaps with a method that needs to "emit" the value and does the replacement by calling a function. I haven't really looked at the problem in details but it looks like we may remove the escape character "too soon" and we end up in another branch that is not aware that it should be escaped. Having a data structure may also simplify a bit of the code.

Food for thoughts, and thanks for looking at it!

snicoll pushed a commit to snicoll/spring-framework that referenced this pull request Oct 10, 2023
This commit adds support for escaping a property placeholder using a
configurable prefix. If a property placeholder is prefixed this way, it
is not resolved. By default, '\' is used but the feature can be disabled
by setting it to null.

See spring-projectsgh-30671
snicoll added a commit to snicoll/spring-framework that referenced this pull request Oct 10, 2023
This commit allows to escape property placeholders to later processed
by user. PropertyPlaceholderHelper allows to set custom escape character. "\" is used as the default one.

Closes spring-projectsgh-9628

Signed-off-by: Dmitrii Bocharov <[email protected]>
@snicoll snicoll added the status: waiting-for-feedback We need additional information before we can continue label Oct 12, 2023
@bdshadow
Copy link
Contributor Author

Tried for some time to solve it. The code really becomes ugly. The problem with the existing mr is indeed that the escape character is removed "too soon". While trying to fix it, I've come up with some more tests, which I'm not sure how they should work:

p1=abc
p2=\${undefined:${p1}}

p3=\${p1}
p4=\${undefined:${p3}}

p5=abc\${

What should p2, p4 and p5 be resolved to?
Should p2 become ${undefined:abc}? Do we want to resolve nested placeholders inside an escaped placeholder? If yes, then p4 must become ${undefined:${p1}}?
A separate case is p5. Should it become "abc${"? Or should it be treated as not a placeholder and stay the same"abc${"?
Probably these are questions to ask in the initial ticket

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Oct 15, 2023
@snicoll
Copy link
Member

snicoll commented Oct 16, 2023

It's fine we can continue here as we're trying to figure out the best way to move forward with the code. Thanks for the follow-up and I am not surprised things get messy with corner cases.

To answer your questions:

  • p2=\${undefined:${p1}} should be ${undefined:${p1}}as whatever that's inside the prefix/suffix that's escaped should be rendered as is.
  • \${undefined:${p3}} same ${undefined:${p3}}
  • abc\${ is a good question. It should be rendered as abc\${ I guess since it's not a valid expression.

I don't know if the above helps or makes it even worse. Let me know :)

@bdshadow bdshadow force-pushed the gh-9628/escape_property_placholder branch from 8a13aee to 97a324d Compare November 1, 2023 16:58
@bdshadow
Copy link
Contributor Author

bdshadow commented Nov 1, 2023

Finally, i've updated it :)
Actually, i added 2 commits. The first one just fixes the problem we discussed above.
In the second one, i tried to introduce a data structure, which you mentioned. I'm not sure if it really helps, but at least it lowers the complexity of the code, which sonar was complaining about. I tried to add 2 classes Property and Placeholder, but in my opinion, it led to more complexity as Placeholder can become a Property and there were unnecessary conversions back and forward all the time.
I also thought about some static initializers like `Property.of(...), maybe it can simplify reading the code too.
Looking forward to your opinion and am ready to polish it further.

@snicoll
Copy link
Member

snicoll commented Nov 2, 2023

@bdshadow I want to acknowledge that I've seen this. Getting the espacing to work is quite involved as we both feared. If nobody beats me to it, I'll need some quality time to review and provide more feedback if needed. That won't happen before we start 6.2 in anger in a month or so.

@bdshadow
Copy link
Contributor Author

bdshadow commented Nov 3, 2023

Thank you @snicoll. Totally understand. Looking forward to it

@snicoll
Copy link
Member

snicoll commented Dec 30, 2023

It turns out quite tricky and, while I don't have a definitive implementation for this, I did rewrite the parser from scratch as I felt this was the only way to address this issue and other issues reported against it. Thanks for the PR and your efforts.

@snicoll snicoll closed this Dec 30, 2023
@snicoll snicoll added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged or decided on status: feedback-provided Feedback has been provided labels Dec 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support escaping prefix and separator in property placeholders [SPR-4953]
4 participants