If we repeatedly call String#replaceAll, we internally repeatedly call the regular expression pattern compilation every time as following:
```java
public String replaceAll(String regex, String replacement) {
return Pattern.compile(regex).matcher(this).replaceAll(replacement);
}
```
The modifications are to keep the compiled pattern.
Therefore, compiling a relatively expensive regular expression pattern does not have to be done every time.
(new, clean PR from required changes on [#1120](https://github.com/spring-cloud/spring-cloud-config/pull/1120#issuecomment-419998469), also having a clean history for merge)
Following the spring-cloud#1003 PR, I went on a likewise PR to add support for [Gitea](https://gitea.io), a Gogs fork.
On that PR there's a comment asking for a small refactor regarding Github and Gitlab PropertyPathNotificationExtractors so, given the reduced scope of the change, also went for it. As spring-cloud#1003 also includes the appropiate files for Gogs support, I also threw them in. And, likewise, GiteePropertyPathNotificationExtractor's spring-cloud#1107 PR.
So this PR ended up having:
* `[Github|Gitlab|Gitee]PropertyPathNotificationExtractor` common behaviour refactored into a `BasePropertyPathNotificationExtractor` class
* spring-cloud#1003 PR (Gogs support), refactored to reuse the `BasePropertyPathNotificationExtractor` class
* spring-cloud#1107 PR (Gitee using webhook contents as PropertyPathNotification), refactored to reuse the `BasePropertyPathNotificationExtractor` class
* Gitea support, using the `BasePropertyPathNotificationExtractor` class
I've mantained author tags on files regarding those PRs, in order to respect code authorship as much as possible (if there's anything missing, I'll gladly add whatever commits necessary). Also, as Github notes that those PRs are already mergeable, their corresponding authors must've signed the corresponding ICLAs, I assume this PR should be safe to merge.
best regards,
juan pablo
Hi. This is an attempt to fix#974 (cc @ryanjbaxter )
As mentioned previously in the ticket, the original code tries to mask out escaped variables (i.e. `\${hello}`) before performing replacement, and then finally removing the escapes before returning.
This works fine for .yaml or .properties, but not for JSON.
The jackson serialization that happens before the property resolution ends up adding an extra `\` (so that the JSON is well-formed) [EnvironmentController.labelledJsonPropertes](https://github.com/spring-cloud/spring-cloud-config/blob/master/spring-cloud-config-server/src/main/java/org/springframework/cloud/config/server/environment/EnvironmentController.java#L169).
I've updated the `resolverPlaceholders` to accept one or two escapes (`\` or `\\`).
I realize this will now treat `\\` as an escape in yml or properties, which may be unintended, but seems unlikely.
An alternative might be to add a flag to this method to indicate whether or not to allow double escape, and updating the `labelledJson` method to pass the flag?
I'm open to any feedback on this approach or another.
Thanks!
We now construct the URL template from the base URL, API version prefix and secret backend upfront and apply templating only for the secret key. This bypasses URL encoding for the secret backend which allows for special characters such as slashes to be passed thru directly.
Fixes gh-1094.
