current implementation can be made to watch certificate and reload on change. that sounds a little complex, and has edge cases, like symbolic links. can it be not made to reload the cert every minute or so? the overhead is minimal, and in most cases time based relaod is sufficient.
https://spring.io/blog/2023/11/07/ssl-hot-reload-in-spring-boot-3-2-0
Comment From: wilkinsona
The code has already been written and, as far as we know, it's working well and hasn't resulted in a big maintenance burden. As such, I don't think the complexity is too high and the edge cases have not (yet at least) been problematic. Given that watching is more efficient and appears to function well, what benefit to users would there be in schedule-based reloading?
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: soloturn
currently it is broken. file watcher checkslast_modified of symlink (which doesn't change) and thus it does not work. and - if this edge case is fixed, another one will pop up. that stuff is file system dependend., on how stuff is mounted etc etc. rebooting and restarting can confuse timings. if one moves in a different file it might get confused. there is so many edge cases, where current implementation breaks.
Comment From: wilkinsona
A problem with symlinks was fixed in 3.3.8 and 3.4.2.
I don’t think we should make a change here based on assumed problems for which there’s no evidence. We can always reconsider if it becomes apparent that the maintenance burden of the current approach is too high.
Comment From: soloturn
@wilkinsona thank you for your welcoming and encouraging messages. you make people live and suffer with the springboot project, let them open a ticket, invest some time, and then brush it aside :) with the argument "hypothetical", while the next error is implemented right into https://github.com/spring-projects/spring-boot/pull/43586 it does not watch the link any more. if the location chagnes, it won't get it. or am i reading wrong?
Comment From: bclozel
@soloturn You started this issue with an enhancement request and it was declined. Then claimed there was a bug and Andy pointed you to recent fixes, stating that we wouldn't consider that behavior change unless there are strong reasons.
You haven't been constructive so far, providing no concrete information (Spring Boot version, repro project, environment). After a comment like that, why should be investing more time in considering your comments?
If you would like to move this forward and report a bug, maybe consider providing us with a sample project and simple directions. We have test cases backing our implementation and nothing from you so far.
Comment From: soloturn
our use case is a kubernetes secret mount into a container, which i believe works using inotify like currently implemented (see here: https://stackoverflow.com/questions/37317003/restart-pods-when-configmap-updates-in-kubernetes). if i get around to test what happens in case secret changes i'll report back. using something like:
inotifywait -m /etc/my-secret -e modify -e create -e delete |
while read path action file; do
echo "Secret file $file at $path was $action"
# Add your logic here, e.g., reload application
done
excuse my irony, should not have done that, @bclozel. was a little overwhelmed by the comment "assumption without evidence". java watcher relies on "inotify". it is known when it works and when not. e.g. symbolic link is a file pointing to another file (makes it 2 files which can change, independent). first implementation was watching link file only, second implementation watches links target file only. mount types also influcence, e.g. NFS or CIFS. edge cases, but not mine though at the moment. dumb reading the cert every minute or so evades all edge cases, without testing these edge cases.