Blazkowicz Kachalov- действительно EJB3 во многом срисован со Spring
Категорически не согласен. EJB3 это EJB2 из которого убрали рутину и прикрутили кастрированую обертку над хибером. На выходе те же яйца, только с хибернейтом.
1. между EJB2 и EJB3 большая разница. Концепция "открепленных" от EJB-контейнера сущностей заметно меняет логику использования EJB-сущностей.

2. в качестве ORM-менеджера в EJB3 можно использовать не только Hibernate (TopLink, Kodo, JDO)


Blazkowicz
Kachalovно ... EJB это стандарт, поддерживаемый многими вендорами, плюс обширные возможности серверов приложений, плюс ...
И что? "Стандарт" это всего лишь слово, а не аргумент.
- для меня слово "стандарт" это аргумент, хотя в данном случае я неточно выразился, лучше было сказать "спецификация". Если есть четко описанная спецификация, работать всегда легче чем с самоделками сделанными на коленке

BlazkowiczОбширные возможности серверов с лихвой покрываются обширными возможностями opensource решений.
- можно подумать что сервера приложений не бывают опенсорсными :)


Blazkowicz Взаимно
J2EE != Java EE

Blazkowicz Kachalov Spring vs EJB3
Из второй части ясно что EJB аннотации - детский лепет по сравнению со всей мощью Spring XML.
- смешно то что аннотации используемые в EJB3 это собственно спецификация JPA (Java Persistence API ) от Sun и игнорировать ее значит поклоняться деревянным идолам вместо того чтобы осваивать новые технологии и идти за мэйнстримом. Уверен что JPA скоро включат в JavaSE, что бы программисты ерундой не занимались.

mikkri expp Kachalov Spring vs EJB3 статья полная профанация
+1
Много воды и не понятно о чем. Задачи у "библиотек" вообще разные, как я их понимаю.
- не въехал о каких "библиотеках" речь?

expp Kachalov- смешно то что аннотации используемые в EJB3 это собственно спецификация JPA (Java Persistence API ) от Sun и игнорировать ее значит поклоняться деревянным идолам вместо того чтобы осваивать новые технологии и идти за мэйнстримом. Уверен что JPA скоро включат в JavaSE, что бы программисты ерундой не занимались.

мне кажется ты не разделяешь JPA (типа как стандартизированный хибер) и остальной EJB3 типа @Stateless @Resource @EntityManager
- да нет, конечно я понимаю разницу между JPA и EJB3, но согласитесь что JPA это неотемлемая часть EJB3 и его основа (в моем понимании основа любой программы - данные, а JPA собственно и определяет представление и связи между данными). Кстати EntityManager это тоже элемент JPA, а вот Stateless, Stateful, MessageDriven это позаимствованно из EJB2. Resource это уже почти JavaSE :)

- можно говорить о том что откуда позаимствованно, POJO Entity из Spring, JPA из Hibernate, но факт что получилось просто и удобно, а то что позаимствованно это нормально, компания Sun хочет идти в ногу со временем и превращает популярные и удачные идеи в спецификации. Странно ими не пользоваться сохраняя верность продуктам "родителям".

Blazkowicz Kachalov1. между EJB2 и EJB3 большая разница. Концепция "открепленных" от EJB-контейнера сущностей заметно меняет логику использования EJB-сущностей.
Ну, понятно дело что POJO лучше чем прикрепленные классы. Но это не больше чем уменьшение рутины.
- другая логика при работе с полями сущности. С одной стороны ValueObject уже реализован на уровне архитектуры, с другой стороны требуется явный merge при изменении полей, т. е. меняется структура EE приложения, меняются акценты. Роль SessionBean-ов немного поменялась.

Blazkowicz
Kachalov2. в качестве ORM-менеджера в EJB3 можно использовать не только Hibernate (TopLink, Kodo, JDO)
Я знаю. В том-то и дело, что интерфейс, который абстрагируется от каждого из этих решений не даёт всех плюсов, потому что скрывает огромное количество преимуществ каждого из них. Врочем JDO, вроде как оказался провальным решением.
Опять же, возвращаясь к производительности. Благодаря тому что JPA скрывает за собой хибернейт, у девелопера исчезает возможность оптимизировать что-то на уровне Hibernate. И когда JPA не устраивает остается только Native SQL. Что собственно так смахивает на ситуацию CMP/BMP. Лучше конечно, но все же...
Аргумент "можно менять реализацию JPA не меняя проект" не канает. Все равно что сказать MVC хорошо потому что можно менять View. Грабли будут в любом случае. Приложение тестируется под каждого вендора отдельно. Перенос крупных приложений ещё ни разу не прошел гладко, не смотря на то что "спецификация всё описывает".
+ 100%

Blazkowicz
Kachalovдля меня слово "стандарт" это аргумент, хотя в данном случае я неточно выразился, лучше было сказать "спецификация". Если есть четко описанная спецификация, работать всегда легче чем с самоделками сделанными на коленке
Четко описанная спецификация зачастую не включает в себя описание ряда моментов. Которые благодаря тому что не включены в спецификацию, превращаются в не четкую головную боль.
"Самоделки на коленке" доказали что способны зарули неповоротливый JCP за раз.
Хибер уделал и EJB и JDO на раз.
Spring тягается с EJB на равных.
Tapestry появился до JSF и до сих пор во многом составляем ему серьезныю конкуренцию. Не отстают и другие web framework-и которые зачастую превосходят "стандартные" JSF/JSP.
Axis, XFire до сих пор для меня предпочтительнее JAXB, JAX-RPC, JAX-WS
Другие opensource проекты по немногу перетягиваются как в J2SE так и в разные JSR спецификаци.

Из всего этого видно, что "стандарт" во многом себя не оправдал. И является тормозом в развитии. С другой стороны конечно его наличие это все же не плохой фактор с точки зрения конкуренции и стабилизации.
- многие опенсорсы погибают, после того как создатели теряют к ним интерес, а фиксация на уровне спецификации позволяет сконцентрировать силы и подтянуть ресурсы коммерческих разработчиков готовых "подкормить" опенсорсников: Geronimo, GlassFish, JBoss

Blazkowicz
Kachalov Blazkowicz Взаимно
J2EE != Java EE
8)) Это к чему замечание? От того что J2SE и J2EE стали JSE и JEE они принципиально не изменились. Привычка вставлять двойку в название ещё долго будет жить.
- книжечка довольно старая, тут vas0 привел интересную ссылку из которой мне (в контексте данной дискуссии) понравилась цитата:
авторRod serves in the JCP on the Expert Groups defining the Servlet 2.4 and JDO 2.0 specifications. His status as a leader in the Java community has been recognized through his invitation to Sun's Java Champions program.
- когда писалась книга еще не было JPA, EJB3 и т. д., а был EJB 2.0/2.1 (J2EE), а это по моим ощущениям, все же большая разница. Раньше я сильно напрягался чтобы объяснить людям что такое EJB, а сейчас это гораздо проще (в смысле легче, доступней).

expp Kachalov но согласитесь что JPA это неотемлемая часть EJB3 и его основа несоглашусь
- а зачем тогда вообще нужно EJB, если исключить работу с данными, т. е. JPA?

expp KachalovPOJO Entity из Spring, в спринге нет entity. в смысе service?
- имел в виду что Entity в EJB3 это те же POJO из Spring

exppя хочу два раза инжектить репозиторий в сервис с разными @PersistenceContext. как это сделать?
- а в чем проблема? например так:

exppможно не делать репозитории SessionBeanами?
- не понял :(