Не нравиться в EJB отсутствие пассивного разрешения зависимостей в DI. Какой там финансовый и гос. сектор, открываем абсолютно любой учебник для школоты по басику и там будет написано, что конфигурацию нужно выносить из кода.

Не нравиться Local и Remote интерфейсы, я чо попугай что-ли повторять одно и то-же по два раза, есть сервис он может делать что-то полезное, а могу я до него рукой достать или мне нужно сделать пару шагов, меня как разработчика это интересовать не должно, это опять же дело конфигурации, которая должна быть вынесенна из кода.

Не нравяться тормоза. Тут конечно Вы придеретесь, как это так, ведь EJB всего лишь спека, а документ тормозить не может, но абсолютно все реализации EJB конкретным производителем которые я видел, без единого шанса сливали спрингу.

Не нравится несовместимость конфигов для разных серверов.

Не нравятся многочисленные лисопеды типа пула stateless объектов, для спрингера это полный идиотизм держать в памяти много полностью идентичных объектов, пул которых еще и может стать бутылочным горлышком, маразм да и только.

eros2Давайте в этой теме обсудим EJB 3.x и смежные технологии звена бизнес-логики - CDI и JPA.

Вы это на полном серьёзе заявили, или Вам на выходных заняться нечем? JPA скопипижжен с hibernate, и постоянно отстаёт от hibernate, так как физически невозможно украсть идею быстрее чем она опубликованна, а CDI до DI от Spring как до парижу раком.

vimba а CDI до DI от Spring как до парижу раком.
Я да же более того скажу, Dependency Injection от спринг не имеет аналогов, в мире такой фабрики объектов, еще не существовало, со Spring можно занжектить что угодно, куда угодно, натовцы были полные идиоты воюя с каддафи, достаточно было обратиться в спринговский саппорт, и там бы заинжектели каддафи ампулу ционистого калия, и всё.

Похоже одержимость EJB, кроме как святой водой и молитвами ничем не лечиться, самое интересное что Вы похоже искренне за него агитируете, а не получаете проценты с откатов от IBM и ORACLE.
авторМожно вынести в beans.xml. Там можно указать alternatives и stereotypes.

Есть у меня интерфейс сервиса для справочников допустим: записать, создать, удалить, найти по критерию. Он универсальный интерфейс и у него возможно и реализация одна, но в рабочем приложении нужно 20-30 экзепляров, короче по числу справочников, каждая реализация сконфигурированна конкретным ДАО которое умеет работать с конкретной сущностью. Как я с помощью альтернатив опишу тридцать реализаций одного и того же интерфейса? Допустим сервис для клиентов представляется как стандартный справочник и мне нужно заинжектить в него в сервис для накладных:
eros2Ну да, конфигурируется всё.

И что по вашему это фича EJB? В spring я не должен копипастить, а в EJB доолжен и это плюс EJB???
eros2Как раз за счёт пула мы получаем скорость, не нужно при каждом вызове создавать объекты, это же маразм - создавать stateless объекты при каждом вызове, правда?

Я под столом. Насколько же нужно быть упоротым на EJB, чтобы в упор не замечать что этот пул вообще не нужен, что он является издержками джамшутовского дизайна, ведь достаточно только одного объекта на каждом экземпляре в кластере.

eros2 Ты могучий воин, респект тебе и уважуха, я бы наверно не смог, так как ты программить на legacy технологии и рискнуть при этом схлеснуться с прогрессивным сообществом, уже очевидно что ты искренне веришь в EJB и не запятнан связанными с ним откатами и распилами, но пора открыть глаза и увидеть новый мир, в котором EJB отводиться роль всего лишь еще одной технологии с которой Spring играючи интегрируется. Spring сегодня стандарт де факто, а EJB всего лишь маленький ослик, который забыл дорогу домой()

eros2На одном экземпляре мы не получим возможность использования instance variables, т.к. они могут быть модифицированы разниыми тредами, а стандарт гарантирует, что никто не тронет ваши instance variables пока идёт выполнение бизнес-метода.
Тут вы можете сказать, что просто не нужно использовать instance variables, нужно обойтись локальными и всё будет хорошо. Однако, представьте, что ваш бизнес-метод вызывает ещё много приватных методов - и если нужно передавать между ними много параметров, то проще использовать именно instance variables, чтобы не описывать кучу аргументов для каждого приватного метода. Так что без пула никак. А один объект на каждом экземпляре в кластере - это уже синглтон получается.
Я просто применю паттерн method object и всё, при том что необходимость method object даже при унылом anemic возникает навскидку только в 60-80% случаев, а при том условии что как првило у меня Rich Domain Model и необходимость method object всегда равна нулю, то пул stateless объектов для меня ненужная ноша.

[quot vimbaпри том что необходимость method object даже при унылом anemic возникает навскидку только в 60-80%[/quot]
Описался, хотел сказать что даже при anemic method object или поля класса не нужны 60-80% случаев

Да не, Вы не так поняли, таких девушек у нас нет. Просто общественность враждебно настроены по поводу EJB, пусть ORACLE хоть в попу теперь целует, но врят-ли человек познавший Spring перейдёт на ежи, а сарафанное радио препятствует входу в EJB3 независимым начинающим разработчикам, Oracle сейчас нужен какой-то нестандартный ход, настолько нестандартный, что никто даже не может предполагать какой, чтобы вернуть доверие: EJB, JSF, JPA, JSP слишком много зафейлившихся стандартов, которые Spring, Hibernate, ZK, GWT рвут как тузик грелку. В то же время всё это барахло Oracle может со спокойной душой списать на SUN, и предложить свои стандарты.

У нас на 9-е чило намечено собрание ростовского JUG, если попадаешь по числам, то пиши в личку, будешь гостем, накормим напоим и спать уложим.

Без обид, eros2 дело не в тебе, я искренне желаю тебе успехов, но дело в том что предложить писать спрингеру код который нужен только для DI, и не связан с бизнес логикой, это всё равно что наблевать ему на ботинки. Тем более что ты раскрыл задачу только двух справочников, а я говорил о 15-20, но естественно не нужно писать двадцать аннотаций, ты здесь никому ничего этим не докажешь, о EJB сейчас говорят уже больше в прошедшем времени, так что не нужно отвечать на мой вопрос полностью.

grasoff.netа покаж-ка своё решение для двух справочников
А что показывать-то приватное поле и set Метод? Ты прекрасно можешь написать это сам за 20-30 секунд.

grasoff.netреально два справочника, да? круто.
Ну я же говорил, что Spring круто, вообще никакой зависимости на фреймворк, меньше кода. По поводу цифры 2, я вообще то писал что сервису для приема оплат нужен справочник клиентов, но если ты так уцепился за цифру два давай дофантазируем задачу и предположим, что понадобился еще справочник типов оплат, тогда выйдем на цифру 2


grasoff.netдело в том, что eros2 написал няшное решение, которое из моих коллег (~200 человек) может предложить пара человек.
и, обрати внимание, в его решении даже сеттеров нет.
Не нужно пожалуста жаловаться на то, что у тебя 198 безграмотных коллег, подобные инъекшены на spring делает сопливый джуниор который работает без году неделя. По поводу сетеров, я могу их спойно убрать так как spring может инжектить приватные поля и без сеттеров, но тогда получиться завязка на spring-framework из-за аннотации которая в этом фреймворке описана, так как по скорости написания сеттер пишется быстрее, по крайней мере в клипсе, поэтому я на фреймворк обычно не завязываюсь, но если б решил завязаться то получилось бы следующие:
Итого получили, что код на spring короче так, как нет самописных аннотаций которые только как для DI, он еще и гибче так как до самого последнего момента не известно ни реализации каких классов будут подставлены, ни как экземплярыы этих классов будут сконфигурированны. Вообще в ежах очень многое пишется исключительно для DI, если ORACLE сможет предложить стандарты на пассивное DI, то в индии поднимется национальное восстание, так как абдурахманы начнут получать меньше денег из-за того, что пишут меньше кода.

И в догонку задачка на размышление, если элементарную может решить двое из двухсот, то я думаю эту не сможет решить никто из ежебэшников:
Классы все те же самые, интерфейс реализация ClientService implements RefService написанна сторонней фирмой распространяется только в бинарниках и не подлежит модификации, никаких эжб аннотаций на ней не стоит. В приложении нужно два экземпляра ClientService по разному сконфигурированных и два экземпляра PaymentServiceImpl, то есть имплиментация одна
PaymentServiceImpl, но количество инстансов 2, и каждому инстансу нужен свой инстанс ClientService, и на всё это накладывается ограничение, что Вы устроились в Европейскую компанию в которой количество исходного кода никак не оплачивается, а платят за результат. Вот пример решения на спринге который никак не затронет исходники, уже готовые компоненты просто по разному конфишурируются: