VoDAСпринг это конструктор. Под него можно подложить EhCache или Terracotta.То есть, я немного перефразирую: Spring не может поднять кластер, но у него есть классы-хелперы, которые позволяют быстро интегрироваться с уже существующим кластером.

BlazkowiczСмелое заявление.Берем типичное JavaEE приложение.
Что инстанцируется в обход Spring:
1) Вся инфраструктура контейнера.
2) Все зависимости используемых библиотек. Примеры: slf4j, xml-либы, javassist, "тысячи их".
3) Все ентити
4) Все локальные объекты
5) В некоторых случаях ... контекст самого Спринга

Что инстанцируется спрингом:
1) Только то, что определено контексто, а именно всякие сервисы, контроллеры и иже с ними (причем достаточно большая их часть являются синглтонами).

VoDAвы пробовали подменить встроенную в сервер библиотеку на более новую версию? Тот же Hibernate апгрейднуть? или встроенную реализацию JSF заменить на более подходящую?
Если либа вложена на уровне сервера, то попытка использовать другую версию может привоить к феерическим багам ввиду наличия в класспасе нескольких версий одних и тех же классов.Конечно пробовал. У нас в одном проекте была седьмая WebSphere, в которой веб-сервисы имплементированы на основе Axis2. А нам надо было подсунуть другую версию Axis2. Делается очень легко:
1) Кладем нашу версию Axis2 в EAR (привет варникам! )
2) Деплоим приложение
3) Изменяем порядок делегирования класслоадера EAR-ника
4) PROFIT - движком веб-сервиса стала наша либа.
У любых современных АппСерверов есть такая возможность.
Очередная попытка обощить либо свое незнание, либо негативный опыт на все ситуации. Это плохая привычка

VoDAЧаще выбор технологии - EJB и JavaEE stack или Spring как клея и огромного количества фреймвороков, которые через него клеятся к приложению.Ничего подобного. Контейнер - это инфраструктура, Spring/EJB - это реализация DI. Поэтому выбор идет так:
1) Определяемся с контейнером
2) Определяемся с реализацией DI - Spring или EJB.
Я повторюсь - большинство проектов, которые я видел крутящимися на сфере, имели в качетсве DI Spring, так как он в большом количестве случаев оказывается гибче и понятнее, чем EJB.

VoDAКак автор этой части обсуждения предлагаю вернуться к изначальной теме "Spring VS JavaEE stack".Проблема в том, что "Spring vs JavaEE stack" не имеет ровным счетом никакого смысла. Сравнивать можно "Spring vs EJB".

VoDAСколько раз вы подменяли серверную реализацию контейнера-EJB на свою? сколько времени потребовалось на поиск и исправление всех багов от этой замены?Выше про делегирование класслоадеров почитайте. Мне не приходилось подменять EJB. Если бы пришлось - пошел бы таким же путем.

VoDAМожно уточнить какие задачи решает EJB и НЕ РЕШАЕТ spriong beans?Я где-то дал повод задать мне такой вопрос?

VoDAв прямой работе с JPA API без декларативного управления транзакциями, без иных фишечек которые может предложить AppServer для EAR или Spring для WAR.Окей, тут возразить нечего. Так как нам в итоге быт ьс вашим утверждением, что JPA не запустится из war без спринга?

VoDAмы помним, что это пункт про EJB 3.0 и что после появления вкусняшечек в Spring появлися EJB Lite в 3.1Про какие именно "вкусняшечки вы говорите"?

VoDAТак вот если Spring использован грамотно и зависимости живут только в applicationContextЯ же вам привел пример - вот у нас есть Хибер. Ему нужна либа для создания проксей, например javassist. Еще ему нужен, например, slf4j. Скажите - вы будете в контексте прописывать какие-либо классы из этих либов?
Я вам намекну еще раз - зависимостями управляет Maven. Если вы где-то используете джарник, которому нужно еще 10 джарников для работы, то вы хоть прописывайте их в контексте (вот только зачем? ), хоть нет - они будут загружены.
Для понимания этих вещей - я вам рекомендую создать Maven проект, запихать туда какие-нибудь известные либы/фреймворки, и посмотреть, что реально от чего зависит.
Утверждение, что Spring оказывает хоть какое-то влияние на зугрзку классов - абсурд.

VoDAДело в том, что Spring это очень умный клей. Он заранее знает что для работы Hibernate требуется одна из либ подходящих для манипуляции байт-кодом. Так вот если ни одной либы не указано явно, то Spring использует default который для Hibernate выставлен в javassist.Очередной абсурд. Допустим, что у нас все настройки Hiber'a по умолчанию. Вопросы вам:
1) Если я инстанцирую SessionFactory не через Spring, а руками через new, то хибернейт сможет понять, какую библиотеку использовать?

VoDAЯ убежден, что все кто сознательно выбирает Спринг работают через IoC - это его база.Ну да. EJB тоже IoC. Вы это к чему говорите?

VoDAEJB для аналогии - попытка создания spring beans через new по сути такой же бред, как и попытка создать EJB компонент через new. И тот и другой компонетнты управляются контейнерами, потому получить их можно только из контекста. EJB запросив у сервера, а spring bean у Spring.Где и кто говорил про создание EJB через new?

VoDAеще перефразируя - Spring помогает создать кластер любой конфигурации. Для упрощения этого процесса в нем заготовлены классы-хэлперы.
Конфигурация кластера JavaEE приложений довольно жестко прошита в сервере.Очередная глупость. Вы мне только что привели пример - Terracota. Мы говорим не про кластеры на основе самих апп серверов, а про сторонние кластеры. Вопрос вам - если я могу настроить Терракоту через Spring, что мне помешает сделать это без него? Да, будет геморенее, тут спору нет.
То есть вы путаете кластеры на основе апп серверов - которые мы создаем через конфигурацию инстансов этих серверов, и 3rd-party кластеры, которые к апп серверу вообще никакого отношения не имеют.

VoDA2) Определяемся с реализацией JavaEE сервера если выбран JavaEE или реализацией web-container если в качестве основного контейнера выбран SpringSpring это не контейнер в понятиях Java контейнеров. Spring это реализация DI. Вы никак не можете это понять.

VoDAа с чем вы будете сравнивать Spring WebServices? а Spring Timers? а Spring MVC?
тут явно не обойтись одними EJB.Эмм, а зчем мне их с чем-то сравнивать? Это не основа спринга, а лишь вспомогательные классы. А Spring MVC и вовсе преследует иные цели, чем DI - это реализация паттерна MVC.

VoDAоно было излишне гротескным - запустится запустится, но настолько неудобно, что лучше бы этого не было ;)Все неудобство из-за отсутствия DI. Достаточно большая часть современных приложений использует DI, это абсолютно естественно, ибо удобно.

VoDAHibernate - конечно пропишу. Логгеры несколько иные по природе, потому их инстанциируют напрямую без привязки к контейнеру.То есть вы отказыаетесь от вашего утверждения, что именно Spring определяет, какие классы/либы грузить, а какие нет?

VoDAОсновной посыл в том, что в условиях если hibernate.jar и javassist.jar лежат в WAR-нике, но в приложении не используются то они не будут загружены.Ок, все верно. Их не загрузит ни Spring, ни Tomcat, ни WebSphere.

VoDAПри этом даже если приложение не использует JMS от сервера. Совсем не использует. Даже в этом случае подсистема JMS все равно будет загружена.И? Какое следствие? Да, JMS скорее всего будет загружен где-то в верхних класслоадерах WebSphere, так как это часть инфраструктуры.

justforsqlruУважаемый svenom как в ejb 2.1 реализуется DI ?
Приведите плиз пример.В EJB2.1 использутеся подход Service Locator, а не Dependency Injection.