Comments 14
Правда эта настройка чуть ли не первое, что включают на реальном продакшне при сколь-нибудь существенной нагрузке
Спорное утверждение
Обычно до Jetty/Tomcat и т.п. стоит, например, nginx, на его уровне и включается сжатие
достали постоянные критические уязвимости в Jetty и переключил сервисы на grizzly
Как то в нем меньше уязвимостей находят.
Jetty в половине случаев используется как встроенный движок для проектов на Spring Boot и тут уже так просто "переключить сервисы" не выйдет.
То, что их не находят не значит, что их нет - возможно просто никто особо не ищет.
А вас не достают требованиями СИБ о том что нужно "сделать так что бы анализатор не показывал уязвимостей".
Причем доводы о том, что эта "уязвимость" в принципе не применима к данному прикладному ПО, просто не принимаются во внимание.
"не должен показывать" и все тут.
Так и довод мой довод, что "gzip" в принципе не может прилететь из этого доверенного источника, не был принят во внимание (если уж источник/канал компрометирован, то от туда прилетит финансовое распоряжение, а не gzip бомба)
"не должно быть.."
Психанул и заменил на grizzly. Благо сервис не на Spring Boot и меняется легко.
А Spring Boot это вообще.. переписывать на 4.x cо старых 2.x потому что "не должно быть сообщений об уязвимости".. Сервисы которым уже по 10 лет (и работают).
А на Spring Boot 2.x.x строчек 20 сообщений об уязвимостях на самой последней версии.
Да лучше бы сразу было написано без оберток Spring Boot. Заменил некоторые либы и все.
А вас не достают требованиями СИБ о том что нужно "сделать так что бы анализатор не показывал уязвимостей". Причем доводы о том, что эта "уязвимость" в принципе не применима к данному прикладному ПО, просто не принимаются во внимание. "не должен показывать" и все тут.
Так тут проблема не в Спринге, а в вашей СИБ - и вы ее "решили" отказавшись от Спринга, но это ж не решение, правильно? Завтра возможности отказаться от чего-то что бы накормить СИБ не будет, и вы обратно окажетесь в такой же ситуации, только вместо Спринга будет что-то еще.
Психанул и заменил на grizzly. Благо сервис не на Spring Boot и меняется легко.
Заметьте, заменили вы не потому, что Спринг плох или Гризли хорош, а потому что нашелся кто-то, кто заставил вас психануть.
А на Spring Boot 2.x.x строчек 20 сообщений об уязвимостях на самой последней версии.
Это говорит только о том, что уязвимости ищут и находят - и вам о них говорят. А, ка я и сказал, то, что в Гризли ничего не найдено вовсе не говорит, что в нем нет дыр размером с верблюда - может их просто не ищут и не сообщают о них, поди знай...
Да лучше бы сразу было написано без оберток Spring Boot. Заменил некоторые либы и все.
Думаю очевидно, что проблема тут ни разу не в Спринге, а в том, что кто-то не хочет включать мозг, и спускает указивки на "устранение уязвимостей" не приходя в сознание.
Думаю очевидно, что проблема тут ни разу не в Спринге, а в том, что кто-то не хочет включать мозг, и спускает указивки на "устранение уязвимостей" не приходя в сознание.
В данном случае, мир под себя не сломаешь. Приходится делать то, за что платят.
А как вам требования для ПО которое отправляется на сертификацию: "все комментарии к коде должны быть на русском и термины то же". Приходится.. удерживаясь от русского мата в комментариях и позволяя себе только фигу в кармане, использования православных терминов "поток" (stream) и "поток" (thrеad) в одной фразе в разных смыслах.
А Спринг мне и по другим причинам не очень нравится.
Очень много ресурсов тянет при старте программы, на фактически динамическую компиляцию (замечательно писать в JpaRepository типа findFirstByEntityIdAndAccount, но это все расходы на старте)
Шаг право - влево и мучительный поиск "как сделать" включая копания в исходниках Спринг.
п1. - на самом деле самый проблемный. Не разработчику. А эксплуатации. Когда на HighLoad++ целое тема была посвящена "как мы запускаем массово сразу много сервисов SpringBoot одновременно, оптимизируя запуск".
переключил сервисы на grizzly
А есть какой-то другой незаброшенный grizzly?
5.0 Jan 20, 2026
"Вам шашечки или ехать"
Честно говоря, не очень понимаю это гонки за версиями и "используем все самое последнее и давайте все перепишем под другой фреймворк".
По производительности или по устойчивости вот ни раза не заметил разницы grizzly с tomcat или jetty.
А так, мне пофиг в каком окружении крутится прикладной код, решающий задачи, которые мне ставит бизнес.
И в принципе использовать javax.ws.rs./jakarta.ws.rs. для задания WEB API или org.springframework.web.bind.annotation.* то же разницы нет особой.
Думаю несложно догадаться, что при таких вводных даже реализация «сторожевого пса» (Watchdog) для сервиса на Java представляет проблему.
эээ. чешу репу. а как же -XX:+ExitOnOutOfMemoryError, -XX:+CrashOnOutOfMemoryError ?
Оно не всегда срабатывает, а генерация crash-репорта на проде - так себе занятие.
Март, Jetty и утекшая память