Comments 21
Не знаю, какая цель в итоге стояла. Но думаю можно было обойтить простым util:constant
не совсем. util:constant позволяет присвоить константы (это может и Value), но он не может
1) присвоить микшированное значение только по интерфейсу, т.е. собрать все бины, которые реализуют некий интерфейс и их присвоить в поле
2) динамически подстраиваться под текущее окружение.
Сегодня у меня один ENUM, завтра три, послезавтра один ENUM «удалили» из сборки
А если в процессе разработки в ENUM добавили новое значение, то вам придётся пробежаться по всем бинам, к которым вы применили util:constant и добавить туда новое значение (насколько мне известно, util:constant не позволяет работать с масками типа "*")
1) присвоить микшированное значение только по интерфейсу, т.е. собрать все бины, которые реализуют некий интерфейс и их присвоить в поле
2) динамически подстраиваться под текущее окружение.
Сегодня у меня один ENUM, завтра три, послезавтра один ENUM «удалили» из сборки
А если в процессе разработки в ENUM добавили новое значение, то вам придётся пробежаться по всем бинам, к которым вы применили util:constant и добавить туда новое значение (насколько мне известно, util:constant не позволяет работать с масками типа "*")
я немного про другое. зачем именно enum? чем не подходит обычный класс, если вы все равно используете интерфейс?
Я исхожу из простого — если есть константы, влияющие или используемые в логике приложения, то их надо делать как enum.
у вас используется интерфейс. псевдо константы, которые вы постоянно меняете/удаляете/добавляется можно заменить на обычные бины (по одному на каждое значение енума) и забыть про весь этот код как страшный сон. @Autowired для массива интерфейсов прекрасно работает.
каждый изгаляется как хочет, конечно. странно что никто из коллег не предложил другого варианта.
каждый изгаляется как хочет, конечно. странно что никто из коллег не предложил другого варианта.
Казалось бы, enum инжектить в виде бина, а столько геммороя, да только нет ясности — как, зачем и при каких обстоятельствах это может понадобиться?
Поддержу вопрос. Зачем инжектить enum?
ну, например я в enum храню роли, которые собираются в группы. роли на проекте фиксированные всегда и почему бы их как константы не оформить? При этом, на каждый модуль удобнее сделать свой enum, дабы не смешивать роли.
ЗЫ: думал это в одном из следующих постов написать более детально
ЗЫ: думал это в одном из следующих постов написать более детально
Что-то я пока не вижу логики. Зачем он в Spring контексте, когда он уже есть в JVM?
Точно не поменяются? Я бы на вашем месте не изгалялся с энамом. Сдали бы какойнить RolesManager и каждый модуль через имплементацию RolesProvider регал бы свои роли в системе. Можно было бы еще и префиксы по имени модуля делать и дать, что бы избегать коллизий, централизованные настройки доступа. Но это так имхо. Никогда бы не додумался инжэктить энам для таких целей(хоть и в C#, но все же:))
если вы обратите внимание, то в конечном итоге enum-ов «нет» при инжекте — они нужны только на этапе поднятия контекста и на этапе написания кода. И да, где-то рядом есть некий RolesManager, который с этим всем работает.
но это всё отходит от данной темы факультатива
но это всё отходит от данной темы факультатива
гыгы, если енамов в итоге нет, а получается Set, то получается статья на тему «Как заинжектить Set, который изначально описан как enum?».
«Ну да лиха беда начало», сказал Иван-дурак, да пошёл копать дальше. (с) из статьи
«Ну да лиха беда начало», сказал Иван-дурак, да пошёл копать дальше. (с) из статьи
Каждый видит то, что хочет видеть — Инструмент всегда в твоих руках.
Абсолютно согласен. Только вот стоит ли описывать геморройный способ выстрелить себе в ногу на java о том как Сет описанный как Енам может быть заинжектенным с кастомными обработками, СупрессВариннгами и прочими прелестями… не понятно до конца. Вроде как опыт, а вроде как… не понятно вообщем.
На самом деле, главный вопрос в этом посте — какую проблему пытается решить автор,
Выдуманную?
Первое предложение:
Из чего следует однозначный вывод, что в посте Вы пытаетесь решить какую-то проблему. Только вот не понятно какую. Сразу вспомнилось: «Иван-дурак, он ведь дурак, он ведь не знает что они бессмертные… взял и поубивал всех.». Так вот: нет, мне не известно что нельзя. И одиночный экземпляр енума отлично получается сделать бином и инжектить, и все экземпляры запихать в сет.
Так что повторяю вопрос: какую проблему Вы хотели решить?
Как известно, в Spring нельзя сделать бины для перечисляемых типов без «костылей» — у этого типа «нет» конструктора.и второе:
В данном посте я попробую обойти это ограничение.
Из чего следует однозначный вывод, что в посте Вы пытаетесь решить какую-то проблему. Только вот не понятно какую. Сразу вспомнилось: «Иван-дурак, он ведь дурак, он ведь не знает что они бессмертные… взял и поубивал всех.». Так вот: нет, мне не известно что нельзя. И одиночный экземпляр енума отлично получается сделать бином и инжектить, и все экземпляры запихать в сет.
Так что повторяю вопрос: какую проблему Вы хотели решить?
выражайтесь корректнее — это не «главный вопрос в посте», а главный вопрос у вас лично. В посте вопросов вообще не поднималось.
Sign up to leave a comment.
Spring и @Autowired для ENUM-типов. Факультатив