Здравствуйте, Sinclair, Вы писали:

S>·>С другой стороны, смотрю я на реальный код и обычно вижу ("Fooing bar moo boo id={}, state={}", someStuff.getRequestId(), someStuff.getState())...
S>Ну, при должной обработке в логе так и будет someStuff.RequestId, someStuff.State.
У меня в уме какое-то разделение — логи должны быть для людей с ролью поддержки, т.е. их явно формируешь для читабельности. Экспозить имена локальных переменных, которые для читабельности кода, люди с ролью программиста — так себе... Притом, когда я рефакторю код, обычно логгирование оставляю неизменным.
Впрочем не знаю, может это навязанная привычка, были бы другие фичи в библиотеке логгирования, привык бы к другому.

S>>>Всё же прочтите статью. После этого можно будет попробовать её разбрать на sharplab.io и посмотреть, что за код генерируется в итоге.
S>>>Разница между C# и интерполяцией из log2j2 не в поведении при отключении логгирования, а в безопасности.
S>·>Это криворукость конкретно log4j. В том же logback (альтернативная реализация того же slf4j api) такого идиотизма нет.
S>Эмм, а в чём конкретно криворукость? В самой идее интерполяции, или в её реализации?
S>Если второе, то как logback решает проблему безопасности?
В самой идее интерполяции, точнее в дизайне "фичи" сделать её рекурсивной. Сейчас поигрался, т.е. log.info("Hello {}", "abc${env:VALUE}efg"), где VALUE=123${env:VALUE2}456, VALUE2=XYZ будет раскрывать ${} до конца:

"Hello abc${env:VALUE}efg"
"Hello abc123${env:VALUE2}456efg"
"Hello abc123$XYZ456efg"

Т.е. как я понял, кому-то это показалось гениальной супер-полезной фичей... и никто не подумал, что это хрень какая-то, да ещё и дырища...
Если подумать... как вообще кому-то в голову такое могло прийти <10 лет назад??! И это в ИТ-индустрии наученной SQL-инъекциями...

Здравствуйте, Sinclair, Вы писали:

S>·>С другой стороны, смотрю я на реальный код и обычно вижу ("Fooing bar moo boo id={}, state={}", someStuff.getRequestId(), someStuff.getState())...
S>Ну, при должной обработке в логе так и будет someStuff.RequestId, someStuff.State.
У меня в уме какое-то разделение — логи должны быть для людей с ролью поддержки, т.е. их явно формируешь для читабельности. Экспозить имена локальных переменных, которые для читабельности кода, люди с ролью программиста — так себе... Притом, когда я рефакторю код, обычно логгирование оставляю неизменным.
Впрочем не знаю, может это навязанная привычка, были бы другие фичи в библиотеке логгирования, привык бы к другому.

S>>>Всё же прочтите статью. После этого можно будет попробовать её разбрать на sharplab.io и посмотреть, что за код генерируется в итоге.
S>>>Разница между C# и интерполяцией из log2j2 не в поведении при отключении логгирования, а в безопасности.
S>·>Это криворукость конкретно log4j. В том же logback (альтернативная реализация того же slf4j api) такого идиотизма нет.
S>Эмм, а в чём конкретно криворукость? В самой идее интерполяции, или в её реализации?
S>Если второе, то как logback решает проблему безопасности?
В самой идее интерполяции, точнее в дизайне "фичи" сделать её рекурсивной. Сейчас поигрался, т.е. log.info("Hello {}", "abc${env:VALUE}efg"), где VALUE=123${env:VALUE2}456, VALUE2=XYZ будет раскрывать ${} до конца:

"Hello abc${env:VALUE}efg"
"Hello abc123${env:VALUE2}456efg"
"Hello abc123$XYZ456efg"

Т.е. как я понял, кому-то это показалось гениальной супер-полезной фичей... и никто не подумал, что это хрень какая-то, да ещё и дырища...
Если подумать... как вообще кому-то в голову такое могло прийти <10 лет назад??! И это в ИТ-индустрии наученной SQL-инъекциями...
Одно оправдывает. Этот подход часто используется в конфигурационных файлах и там оно действительно полезно. Но конфиги — таки доверяемый код. Короче, запилили фичу "как у всех" не подумав.