defender777tumblerrr,
Это любому AS "нахрен не уперся" spring. А спрингу (как всего лишь фреймверку) просто необходим для работы как минимум десктоп апп, как максимум AS.
Где здесь чушь, знаток?
Клею нужна как минимум бумага, как максимум пластик. Поэтому клей - говно. Пластик круче. :)

defender777бред
Вот вы с tumblerrr и сошлись во мнении.
Бумага это отдельные opensource решения.
Spring это универсальный клей.
Пластик это цельно-вылитый JEE контейнер.
Кто-то модельки из бумаги клеит. Кто-то целиком отлитые формы использует.
Это никак не отменяет надобности клея, в целом.

defender777Да не выходит у вас вывести на чистую воду.
Я и не пытаюсь.

defender777Потому что это клей о котором вы говорите в ентерпрайзе не нужен (не обязателен) ну иначе он бы давно был бы там.
JEE очень инертная система. Нельзя так просто взять и добавить туда Spring. Но вот CDI, как и весь JEE 5 появился под давлением Spring, в котором просто, удобно и прозрачно. В JEE решили сделать хоть бы удобно и, отчасти, просто. О прозрачности речи не идёт.

defender777Даже пусть и хороший клей, но принципы его работы другие.

Именно, поэтому сравнение JEE и Spring как альтернатив не имеет смысла. Это разные технологии, реализующие разные задачи.

defender777Да отдельные идеи энтерпрайз перенимает, даже слышал что разработчики spring сейчас участвуют в разработке спеки.(может это только слухи)
Ну, CDI ещё доделывать и доделать. Так что почему бы и нет.

defender777Но спринг появился и стал полезен во времена EJB 2 как легковесныйы фреймворк для вебконтейнеров в пику тяжелым EJB2.
Вы снова показываете свою неосведомленность в вопросе.
Spring изначально был IoC контейнером и не более. Причем одним из нескольких.
Позже он стал IoC в более широком смысле, интегрируя не только классы, а целые API. Тут-то все и поняли, что от EJB смысла не так много осталось - всё тоже самое можно реализовать на Spring, только проще.
EJB3 не являются "менее тяжеловесными" чем EJB2. Это всё теже самые старые добрые EJB, но с упрощеным синтаксисом.

defender777Но все же меняется.Ситуация другая уже.EJB уже 5 лет как 3.1 а в середине 2013 обещают 3.2. С новыми плюшками.И я не считаю клей за г... :) Просто считаю сравнивать тут нечего.
Ну, так и не сравнивайте больше:
defender777Скажите мне спосообен ваш спринг обеспечить распределенность между серверами приложений как это делает EJB? Есть в нем JMS? Спринг на аппсервере это пятое колесо в телеге.

defender777И в EE свой клей не хуже имеется.
1) Унылый CDI даже рядом не валялся со спринговым IoC.
2) JEE вообще никак не решает задач интеграции сторонних решений. Вот пришла светлая мысль в голову интегрировать Hibernate. И чем это закончилось? Унылой спицификацией, которая покрывает около 50% функциональности и коду вида.
((HibernateEntityManagerImpl)em).getSession().getConnection();
3) В JEE сервере что прибито, то и используйте. Вон у людей в GlassFish веб-сервисы не подымаются после перезагрузки. И что им делать? Им бы взять другой провайдер JAX-WS и поставить на сервер. Но это же не Spring. Тут так просто ничего не заменить.

schwaа эти "сервера" и "контейнеры" до сих частенько кидают OOM: PermGen при редиплоях.
Это вызвано исключительно утечками в самих приложениях.

defender777И в EE свой клей не хуже имеется.
4) schwa напомнил о процессе деплоймента. Сколько там времени нужно чтобы простейший HelloWorld jar развернуть в GlassFish? Spring-контейнер готов к использованию немедленно. Скорость развертки упирается лишь в инициализацию используемых бинов.
Тут вообще в JEE палка о двух концах. С одной стороны все оптимизируют start-up и deployment time. Довольно важный показатель для 24x7 сервисов. JBoss вроде каких-то даже успехов добился. Но это абсолютно идёт в разрез с тем, что теперь приходится ВСЕ классы сканировать на предмет наличия аннотаций во время деплоймента.

defender777Деплоймент на GF 3.1.2, ear в нем15 stateless бинов занимает не более 15 секунд вместе со стартом сервера. Точно кажется 10 сек если указано редеплой а не рестарт сервера. Так что GF не такой уж и тормоз как вы считаете. Дайте ресурс и будет рабтать.
Блин, не смешите.
https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_Web_Platform/5/html/JBoss_Microcontainer_User_Guide/sect-JBoss_Microcontainer_User_Guide-The_Virtual_Deployment_Framework-Scanning_Classes_for_Annotations.html

http://java.net/jira/browse/GLASSFISH-16560
(сервер лежит, можно почитать в кеше)
http://webcache.googleusercontent.com/search?q=cache:vichg4Q7YcEJ:java.net/jira/browse/GLASSFISH-16560+&cd=1&hl=en&ct=clnk&client=firefox-a

GLASSFISH-16560Glassfish 3.1.1 b04 original: 400 s
Glassfish 3.1.1 with dol patch: 170 s
Glassfish 2.1.1 b31g-fcs: 40 s

defender777как раз спринг создает объекты при старте причем все сразу.(40 сек. за каждый деплой это расстрел я ухожу пить чай ))) и это долго. спринг все держит в памяти даже если бин за 5 лет ни разу не использовался или я не прав?

http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/beans.html#beans-factory-lazy-init
Да. По-умолчанию всё eager.
В JEE тоже самое, с той лишь разницей что в Spring это поведение можно контролировать.

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

defender777и могут выгружаться контейнером при необходимости . или нет?
Не припомню такого. Вы про passivate что ли? Оно для stateful только актуально и вообще представляет из себя сомнительную ценность.

defender777вы где это нашли в клубе любителей архитектуры 486 ?
Ссылки привел же.

defender777Проверил. У бина происходит событие PostConstruct только после непосредственного обращения к нему со страницы. Это событие не происходит во время деплоймента. В спринге же видно что все бины создаются в момент деплоймента.
Это решаемо
http://static.springsource.org/autorepo/docs/spring/3.2.0.M1/api/org/springframework/context/annotation/Lazy.html

defender777 Более того разве нельзя разбить проект на множество EJB модулей и деплоить только то над чем в данный момент работаешь?

Аналогично, можно бить спринговый проект на разные котексты. Только зачем?

defender777а весь ear пересобирать и деплоить достаточно только один раз для отправки ear пользователю?

Это чревато, так как тестировать нужно интегрированые компоненты не только по отдельности.

defender777при желании каждый EJB видимо можно деплоить на свои сервера разве это плохо? такая распределенность доступна в спринг?
Можно. Правда не встречался с тем чтобы это было особенно нужно. Деплой всего проекта занимает считаные секунды.

defender777stateless тоже уничтожаются из пула если нагрузка спадает... спринг напротив продолжит хранить статично в памяти все что создал. может я ошибаюсь?
Зависит от Scope