VS
с чего бы нулл по дефолту будет? спринг поищет бин в контексте, не найдет и совершенно справедливо упадет
Size: a a a
2020 June 11
AL
Сейчас спокойно нулл и все если профиля нет.
AL
с чего бы нулл по дефолту будет? спринг поищет бин в контексте, не найдет и совершенно справедливо упадет
Нит
AL
с чего бы нулл по дефолту будет? спринг поищет бин в контексте, не найдет и совершенно справедливо упадет
Не падает на удивление
VS
и даже UnsatisfiedDependencyException не падает?)
AL
Но спорить не буду. Возможно я что-то не досмотрел или не увидел
VS
ну чудеса.
AL
Спасибо. Полезно
VS
на здоровье)
RS
Не падает на удивление
А вот это странно. За последние дни уже пару раз такое видел в этом чатике от разных людей. Мол, бина нет, зависимость от него есть, но вместо привычного UnsatisfiedDependencyException при запуске контекста там просто null. При этом
Как вы инжектите тот бин, который просто становится null-ом, если не найден? Через консруктор, сеттер или
required=false тоже нет. Никогда не видел такого поведения. Если у вас правда так, было бы интересно понять, почему.Как вы инжектите тот бин, который просто становится null-ом, если не найден? Через консруктор, сеттер или
@Autowired над полем?AL
Ruslan Stelmachenko
А вот это странно. За последние дни уже пару раз такое видел в этом чатике от разных людей. Мол, бина нет, зависимость от него есть, но вместо привычного UnsatisfiedDependencyException при запуске контекста там просто null. При этом
Как вы инжектите тот бин, который просто становится null-ом, если не найден? Через консруктор, сеттер или
required=false тоже нет. Никогда не видел такого поведения. Если у вас правда так, было бы интересно понять, почему.Как вы инжектите тот бин, который просто становится null-ом, если не найден? Через консруктор, сеттер или
@Autowired над полем?Конструктор.
VS
да быть не может. в жизни такого не видел если честно)
если без required=false, офк
если без required=false, офк
RS
Ну типа хардкодить названия профилей не очень хорошо. Но если профилем выбираем настройку, мы же в любом случае тогда хардкодим название профиля. Тогда почему нельзя использовать название профиля где-то еще.
Не совсем так.
Если профилем выбираем настройку, то мы хардкодим название настройки, а не профиля (хотя название настройки можно не хардкодить, а использовать @ConfigurationProperties биндинг, что рекомендуется в 99% случаев сейчас). Название профиля у нас хардкодится в этом случае только при задании значения свойства
А гибкость тут появляется в том, что теперь вы в любом профиле можете прописать
Конечно, если вам вот прям вообще такая гибкость не нужна, то можно к имени профиля привязаться. Но лучше тогда сделать это в @Configuration классе, а не бине.
Бины не должны ничего знать ни о каких профилях, это не их область ответственности.
Хотя технически, понятное дело, что можно и так, и так.
Если профилем выбираем настройку, то мы хардкодим название настройки, а не профиля (хотя название настройки можно не хардкодить, а использовать @ConfigurationProperties биндинг, что рекомендуется в 99% случаев сейчас). Название профиля у нас хардкодится в этом случае только при задании значения свойства
spring.profiles.active. В коде оно не нужно.А гибкость тут появляется в том, что теперь вы в любом профиле можете прописать
proxy=true и получите нужное поведение. Частенько это поведение напрямую от названия профиля-то не зависит, даже если сразу кажется, что это так. А потом раз, и внезапно вдруг нужно, чтобы был активен профиль local, но при этом эта настройка все равно была включена. Это можно решать через include доп. профилей, но тогда с доп профилем подтянутся и другие их настройки, а вам вот надо только эта.Конечно, если вам вот прям вообще такая гибкость не нужна, то можно к имени профиля привязаться. Но лучше тогда сделать это в @Configuration классе, а не бине.
Бины не должны ничего знать ни о каких профилях, это не их область ответственности.
Хотя технически, понятное дело, что можно и так, и так.
VS
Ruslan Stelmachenko
Не совсем так.
Если профилем выбираем настройку, то мы хардкодим название настройки, а не профиля (хотя название настройки можно не хардкодить, а использовать @ConfigurationProperties биндинг, что рекомендуется в 99% случаев сейчас). Название профиля у нас хардкодится в этом случае только при задании значения свойства
А гибкость тут появляется в том, что теперь вы в любом профиле можете прописать
Конечно, если вам вот прям вообще такая гибкость не нужна, то можно к имени профиля привязаться. Но лучше тогда сделать это в @Configuration классе, а не бине.
Бины не должны ничего знать ни о каких профилях, это не их область ответственности.
Хотя технически, понятное дело, что можно и так, и так.
Если профилем выбираем настройку, то мы хардкодим название настройки, а не профиля (хотя название настройки можно не хардкодить, а использовать @ConfigurationProperties биндинг, что рекомендуется в 99% случаев сейчас). Название профиля у нас хардкодится в этом случае только при задании значения свойства
spring.profiles.active. В коде оно не нужно.А гибкость тут появляется в том, что теперь вы в любом профиле можете прописать
proxy=true и получите нужное поведение. Частенько это поведение напрямую от названия профиля-то не зависит, даже если сразу кажется, что это так. А потом раз, и внезапно вдруг нужно, чтобы был активен профиль local, но при этом эта настройка все равно была включена. Это можно решать через include доп. профилей, но тогда с доп профилем подтянутся и другие их настройки, а вам вот надо только эта.Конечно, если вам вот прям вообще такая гибкость не нужна, то можно к имени профиля привязаться. Но лучше тогда сделать это в @Configuration классе, а не бине.
Бины не должны ничего знать ни о каких профилях, это не их область ответственности.
Хотя технически, понятное дело, что можно и так, и так.
Руслан, научи так же обстоятельно излагать мысли...
RS
Руслан, научи так же обстоятельно излагать мысли...
Нужно просто не лениться писать стены текста) А на это не всегда бывает настроение или время. Чаще всего хочется написать в 3х словах, но как правило получается сумбурно и вряд ли понятно. Хоть большинство и не любит стены текста, но без них зачастую никак. )
VS
да, думаю ты прав. если б было чуть менее впадлу расписывать все досконально и с примером - вероятно, у меня получилось бы повествование с аналогичным смыслом. собственно, с твоей позицией по вопросу с профилями я полностью солидарен)
AL
Ruslan Stelmachenko
Не совсем так.
Если профилем выбираем настройку, то мы хардкодим название настройки, а не профиля (хотя название настройки можно не хардкодить, а использовать @ConfigurationProperties биндинг, что рекомендуется в 99% случаев сейчас). Название профиля у нас хардкодится в этом случае только при задании значения свойства
А гибкость тут появляется в том, что теперь вы в любом профиле можете прописать
Конечно, если вам вот прям вообще такая гибкость не нужна, то можно к имени профиля привязаться. Но лучше тогда сделать это в @Configuration классе, а не бине.
Бины не должны ничего знать ни о каких профилях, это не их область ответственности.
Хотя технически, понятное дело, что можно и так, и так.
Если профилем выбираем настройку, то мы хардкодим название настройки, а не профиля (хотя название настройки можно не хардкодить, а использовать @ConfigurationProperties биндинг, что рекомендуется в 99% случаев сейчас). Название профиля у нас хардкодится в этом случае только при задании значения свойства
spring.profiles.active. В коде оно не нужно.А гибкость тут появляется в том, что теперь вы в любом профиле можете прописать
proxy=true и получите нужное поведение. Частенько это поведение напрямую от названия профиля-то не зависит, даже если сразу кажется, что это так. А потом раз, и внезапно вдруг нужно, чтобы был активен профиль local, но при этом эта настройка все равно была включена. Это можно решать через include доп. профилей, но тогда с доп профилем подтянутся и другие их настройки, а вам вот надо только эта.Конечно, если вам вот прям вообще такая гибкость не нужна, то можно к имени профиля привязаться. Но лучше тогда сделать это в @Configuration классе, а не бине.
Бины не должны ничего знать ни о каких профилях, это не их область ответственности.
Хотя технически, понятное дело, что можно и так, и так.
Так а разве в конфигурации не надо делать @Profile, если эта конфигурация только с профилем активна? Может я не то понял
VS
Так а разве в конфигурации не надо делать @Profile, если эта конфигурация только с профилем активна? Может я не то понял
конфигурацию можно активировать по @ConditionalOnProperty , а дальше этой пропертей управлять как твоей душе угодно. можно профилем, можно через -Dproperty в строке запуска, можно через переменные среды. получается гораздо гибче.
VS
а чтобы иметь fallback имплементацию твоего сервиса я уже предлагал пользоваться @ConditionalOnMissingBean
VS
собственно это самая частая связка аннотаций которыми я пользуюсь при необходимости такой подмены реализации