AE
какая задача решается?
в плане инфы какую дает.
мне то жесть как нравится
Size: a a a
2020 August 19
C
Посмотри Спринг построитель.
AM
Посмотри Спринг построитель.
смотрел
и потрошитель тоже
и потрошитель тоже
C
Тогда у тебя есть примерно такая же инфа от Борисова, что и у меня.
IS
это как? каким ключом? может нужен https?
Там гостовое шифрование идёт, протокол общения с партнёром требует шифровать тело. Есть класс который шифрует. Осталось только тело подменить
AE
Там гостовое шифрование идёт, протокол общения с партнёром требует шифровать тело. Есть класс который шифрует. Осталось только тело подменить
смотри на цепочку обработчиков, фильры, конверторы сообщений
RS
Получать из свойств окружения. В проперти-файле пишешь типа
spring.datasource.password=${myapp.dbpass} , и приложение запускаешь с ключом -Dmyapp.dbpass=lalal или свойством окружения MYAPP_DBPASS=lalal, В оф. доке по получению свойств всё хорошо всё изложено.
spring.datasource.password=${myapp.dbpass} , и приложение запускаешь с ключом -Dmyapp.dbpass=lalal или свойством окружения MYAPP_DBPASS=lalal, В оф. доке по получению свойств всё хорошо всё изложено.
Недостаток этого подхода в том, что у спринга нет возможности "unset" для свойства конфига. А в некоторых его автоконфигурациях (сейчас уже не вспомню, каких, но точно с таким сталкивался) поведение значительно отличается, если свойство задано в хоть какое-то значение и не задано вовсе.
И вот если мне хочется дать возможность оставить свойство не заданным, т.е. вообще не задавать его, то при таком подходе эта возможность теряется.
Даже если я не задам ENV variable, строка
Конкретно для пароля БД это, конечно, не срашно - там вроде бы никакой хитрой логики нет. Но для каких-то других свойств она есть.
И вот если мне хочется дать возможность оставить свойство не заданным, т.е. вообще не задавать его, то при таком подходе эта возможность теряется.
Даже если я не задам ENV variable, строка
spring.datasource.password=${myapp.dbpass} сделает свое дело. Даже если туда дефолтное значение указать (spring.datasource.password=${myapp.dbpass:def_pass}), все равно это будет дефолтное значение, а не unset и автоконфигурация будет это воспринимать, как установленное значение и идти по другому пути авто-конфигурирования.Конкретно для пароля БД это, конечно, не срашно - там вроде бы никакой хитрой логики нет. Но для каких-то других свойств она есть.
C
Гуд поинт
C
Kevin Lozada, если ты не бот, нажми "четыре". Ботов удалено: 147.
VS
Ruslan Stelmachenko
Недостаток этого подхода в том, что у спринга нет возможности "unset" для свойства конфига. А в некоторых его автоконфигурациях (сейчас уже не вспомню, каких, но точно с таким сталкивался) поведение значительно отличается, если свойство задано в хоть какое-то значение и не задано вовсе.
И вот если мне хочется дать возможность оставить свойство не заданным, т.е. вообще не задавать его, то при таком подходе эта возможность теряется.
Даже если я не задам ENV variable, строка
Конкретно для пароля БД это, конечно, не срашно - там вроде бы никакой хитрой логики нет. Но для каких-то других свойств она есть.
И вот если мне хочется дать возможность оставить свойство не заданным, т.е. вообще не задавать его, то при таком подходе эта возможность теряется.
Даже если я не задам ENV variable, строка
spring.datasource.password=${myapp.dbpass} сделает свое дело. Даже если туда дефолтное значение указать (spring.datasource.password=${myapp.dbpass:def_pass}), все равно это будет дефолтное значение, а не unset и автоконфигурация будет это воспринимать, как установленное значение и идти по другому пути авто-конфигурирования.Конкретно для пароля БД это, конечно, не срашно - там вроде бы никакой хитрой логики нет. Но для каких-то других свойств она есть.
Кстати невозможность ансетнуть меня расстраивает иногда(
VS
Но в общем случае исправляется рефакторингом))
EI
можно в спринге опшинал вериаблс в линке передавать за знак вопроса?
http://smth?v1=a&v2=b2020 August 20
I
required=false
EI
Спасибо
C
Anthony Less, если ты не бот, нажми "пять". Ботов удалено: 147.
VE
Всем привет, слышал мнение, что spring data хороша только на старте разработки, пока не совсем понятно с чем придется дальше работать. А когда требования уже определены и разработка пошла стоит перейти на что-то другое. Мой прошлый проект был на jdbc, все связи были неявными и связанные сущности доставались через запросы. Сейчас я столкнулся с тем, что проект со spring data и начинает появляться большое кол-во many-to-many, соответственно куча сводных таблиц, аннотаций и маппингов entity, но запросы всё равно кастомные. Есть ли смысл перейти на jdbc или как?)
AE
Всем привет, слышал мнение, что spring data хороша только на старте разработки, пока не совсем понятно с чем придется дальше работать. А когда требования уже определены и разработка пошла стоит перейти на что-то другое. Мой прошлый проект был на jdbc, все связи были неявными и связанные сущности доставались через запросы. Сейчас я столкнулся с тем, что проект со spring data и начинает появляться большое кол-во many-to-many, соответственно куча сводных таблиц, аннотаций и маппингов entity, но запросы всё равно кастомные. Есть ли смысл перейти на jdbc или как?)
зависит от того с чем удобнее и с чем привык. большое количество маппингов ничего плохого, а появление явных констреинтов в бд даже только плюс как по мне
АР
для spring data характерно то, что иногда нужно контролировать генерацию запроса
АР
для оптимальности и перфоманса