VoDAОпять же многие идеи обкатанные на Спринге интегрируют в JSR-спеки и стандартизуют.Какие например?

VoDAвозможность конфигурировать сервлет через аннотацию, не прописывая в web.xmlКак это относится к Spring - непонятно.
VoDACDI хотя, возможно, CDI больше наследник Guice, чем SpringС натяжкой можно признать, хотя это не классический DI и не замена EJB.
VoDAпоявление профилей как реакция на то, что Спринг может подниматься только с требуемым набором технологий , а JavaEE всегда запускал все-что-только-можно, даже если большая часть технологий не применяетсяВообще непонятно о чем речь. Что грузит всегда? Кто грузит всегда? С чего вы вообще взяли, что на решение внедрить профили оказал влияние именно Spring? Вы, часом, не с Maven перепутали? Очень похоже на ничем не подтврежденные фантазии.
VoDAвозможность использовать JPA внутри WAR0_о Причем тут спринг вообще?

VoDASpring - один из первых (или первый) фреймворк удобно реализовавший эту возможности. JavaEE повторил удобный опыт.Хоть убейте - не могу понять, о чем вы говорите. Как спринг связан с сервлетами? Может быть вы про Spring MVC говорите?
А как спринг с аннотациями связан? Аннотации - это глобальный тренд, его используют и JPA, и JAXWS, и вские биндинговые фреймворки, и XML-фреймворки, и Hibernate, и Spring, и т.д.. Как можно утверждать, что аннотации в сервлетах - это веяние Спринга - непонятно.

VoDAПопробуйте закинуть Entity в WAR и развернуть на JavaEE 5 совместимом сервере. Оно взлетело?
Теперь в WAR добавляется Spring (с настройкой для Hibernate) и закидывается на Tomcat. Оно уже взлетит.Опять логическая ошибка. Оно взлетает не из-за спринга, а из-за хибера. Я могу спокойно засунуть в варник ентити и хибер и он взлетит. Спринг тут вообще ни при чем.

VoDAЗапустите JBoss с приложением использующим только сервлеты. Сколько не нужных (не запрошенных приложением) подсистем взлетает только потому что JavaEE обязывает?
Запустите Tomcat со Spring. Сколько не нужных систем поднимет Спринг? Тут ноль поскольку конфигурируется только то, что используется и не более.
Спринг заметно быстрее поднимает приложение просто потому, что грузит ровно то, что требуется и не более.Опять логическая ошибка. То, что грузит сервер, никак не свзано с тем, что грузит приложении. Если я запускаю томкат, то это как бэ вообще не сервер приложений, он запустит только контейнер сервлетов . Если я запускаю WebSphere, то само собой, она грузит дохрена чего, так как это сервер приложений, и он расчитан на широкий круг задач. Там и EJB, и WebServices, и JNDI, и еще куча всего. Спринг опять таки тут абсолютно ни при чем. Вы сравниваете принципиально разные продукты и каким-то образом пытаетесь запихнуть сюда спринг

VoDAМоя мысль - тренд применять аннотации вместо web.xml для конфигурирования сервлетов начал Spring.Все равно ничего не ясно. Вы про какие аннотации вообще говорите? @Controller и иже с ними?
Вывод: Spring не давал и не дает аннотаций типа @WebServlet. Для Spring MVC входной точкой является сервлет, который определен в web.xml.

VoDAТренд давать возможность в WAR работать с JPA в JavaEE навеяна Spring. Spring довольно удобно реализовал и заместил JavaEE во многих проектах.А вы можете объяснить, почему именно это неваяно именно Spring? Я вот свой контраргумент привел - Хибер спокойно работает в JavaEE5 баз Спринга, Хибер через JPA тоже спокойно работает в JavaEE5 без спринга. В чем здесь заслуги Spring?
Вывод: что хибер, что JPA спокойно работают в JavaEE5 без спринга, следовательно он тут вообще нипричем.

VoDAИдея не грузить то, что не нужно пришла в JavaEE под давлением со стороны Spring.Ок, вопрос: каким образом Спринг решает, что грузить, а что нет? Если мне не изменяет память, то определением набора используемых библиотек занимается в первую очередь сборочны тулзы, аля Ant/Maven. Спринг же вообще никак не управляет загрузкой тех или иных компонентов. И ваш пример с Томкатом крайне странный. Вы берете контейнер сервлетов, запихиваете в варник кучу либов и довольно утверждаете: "На томкате то грузится только то, что надо!". Ну конечно, ведь до того, как вы загрузили туда варнки с либами (например, всякие EJB< JPA, JAXWS...), их там мообще не было. Я с таким же успехом могу сказать: вот как круто, я запустил десктоп приложение и оно загрузило только то, что нужно!
Немного оффтоп - и что это за такое мифическое преимущество "быстрый старт ервера и приложения"? У вас в продакшене приложения и сервера стартуют/перестартуют по 100 раз на дню?
Вывод: судя по всему, вы перепутали Spring и Ant/Maven.


VoDAя сравниваю возможности предоставляемые Tomcat+Spring с одной стороны и WebSphere с другой. Учитывая, что мне из этой кучи нужно 3-4 технологии. Остальное просто бессмысленно запускается.
К примеру WebServices- если ни одно приложение не пользуется WebServices эта служба не должна запускаться и тратить время в разработке и ресурсы в продакшене. К этому сейчас и подходят в JavaEE.Ок, мне тут нечего добавить к тому, что я написал выше. Спринг никоем образом не управляет тем, что грузить, а что нет. Это ответственность сборщиков и настройки класслоадеров.

VoDAОсновная мысль в том, что проигрывая связке T+S в кастомизуемости и минимизации запускаемых сервисов JavaEE начала терять аудиторию . И для сохранения потребителей они ввели профили, которые и позволяют (по крайней мере на слайдах презентаций ) настраивать JavaEE complaint сервера так же гибко, как это позволяет связка T+S.Очень забавная мысль. Вы считаете, что из-за того, что Томкат стартует за 5 секунд, а та же WebSphere за 50, она потеряет аудиторию в пользу Spring?
Вы немного путаете - на проектах, где хватает томката (простенькие сайты и корп. приложения), используют Томкат. Если требования к приложению указывают, на то, что надо использовать полноценный сервер приложений, то используют сервер приложений. И уж поверьте, время старта сервера, никогда не является причиной выбора Томката в пользу сервера приложений
Вывод: логическай ошибка в рассуждении, непонимание на основании чего выбирают платформу для приложения.

И для сохранения потребителей они ввели профили, которые и позволяют (по крайней мере на слайдах презентаций ) настраивать JavaEE complaint сервера так же гибко, как это позволяет связка T+S.

1) Что использует приложение? Если ему нужно EJB, JPA с XA транзакциями, то что проще - купить ту же WebSphere с уже готовыми реализациями EJB, JPA и иже с ними, где IBM их будет вылизывать с ного до головы, оперативно реагировать на баги и предоставлять прочие плюшки лицензионного ПО, или же взять Томкат, в который потом запихнуть какой-нибудь опен-сорсный OpenEJB, разработчики которого вам ничего не должны + хз, как оно вообще заведется с томкатом? Если приложение мелкое, а бабал нет - не вопрос, мудимся с Tomcat, если с деньгами нормуль - покупаем готовое коробочное решение, вместо попыток скрестить коня с ослом.
В такие плюшки AppServer-ов входят EJB, JDBC - всякие коннекшн пулы, WebService - с кучей всякий плюшек по всяким WS-Security, WS-Adressing и прочих WS-*, JMS и т.д.
2) Возможности инфраструктуры. Вот нужно моему приложению работать с MQ, оно заведется на Tomcat? Ну, с кучей возни и проблем, гляди и заведется. А в сфере заводится с пол-щелчка, используя все плюшки и особенности MQ.
А вот мне надо приложение воткнуть в ESB-шину. Что делать? В той же сфере шина поднимается в лет, мгновенно интегрируется со всякими security realm'ами и JMS'ами. А томкат что?
Далее - кластеризация и кеширование, high availability. У каждого вендора свои плюхи
3) Остальные плюшки - например, проприетарные IDE или проприетарные обкатанные JVM, например для RAD, AIX. У меня ребята в соседнем проекте работают в RAD, пищят от восторга. Не потому, что он универсален, а потому что на их требования он лег идеально. А вот у меня тоже проект на WebSphere, но мне RAD не пошел - другие технологии, он просто не нужен.
4) Чуть не забыл - а как с еарниками то быть? Томкат еарники не понимает, его политика класслоадеров весьма топорная, (почитайте на досуге, как работают класслоадеры в Tomcat, и что можно делать с класслоадерами в WebSphere)

Общий вывод - любые сервера, любые контейнеры это инфраструктура. Выбор того или иного контейнера осуществляется, исходя из:
1) Функицональных требований
2) Нефункциональных требований (банально, правда? )
3) Бюджета
4) Опыта команды
5) Политической подковерной волокиты - будем честными, она имеет место быть.