Помнится мне уже был подобный опрос, но время идет и популярность серверов меняется... Замечу, список также включает просто web-контейнеры, а не только полноценные сервера приложений.
Было бы очень полезно, если при ответе, вы поясняли какие технологии для приложения на нем используются и были ли какие проблемы с совместимостью. Например: "Использовали JBoss 4.2.2. Приложение было построено на JBossWS, EJB, JPA. Были проблемы с передачей транзакции между веб-сервисами и EJB. Решить их не смогли, написали свой workarround.  В остальном проблем не было". Или: Использовали JBoss, при нескольких  редиплоях spring приложения падал с PermGen исключением. Отказались от него, перешли на WebLogic, там все ОК." ... ну в общем в таком роде...


P.S.: Если какого сервера не хватает, пишите, добавим.

tomcat  jboss  glassfish   

Зависит от проекта. Последние были такие:
WebSphere 6.1, WebLogic 9.2 + JBoss AS 4.2.2

JBoss (ejb, jpa, ws) - текущие задачи решает
Apache Tomcat
SunOne Web Server (поддержка старого проекта)

проголосовал за Geronimo, а имел ввиду его EJB контейнер OpenEJB - легкий в использовании, на нем удобно осваивать технологии J2EE.

Количество ответов впечатляет и радует...   

А что отвечать то? Какой сервер заказчик хочет такой и используем, а так стандартно Tomcat...

Ипользую JBoss. Начал еще с 3.x, теперь 4.2.3 Надеюсь добраться до 5.0
ejb2, ejb3, web (jsp, jsf, eclipse rap), ws, ejb3 persistence, JMS, JMX, jboss aop

Из неприятных особенностей:
1. не получается на ходу передеплоить *.war
Приходится останавливать сервер, чистить его временные каталоги. Но это, похоже, бага томката.

2. при переходе 4.2.0 - > 4.2.1 получил кучу проблем с local-tx-datasource при использовании нескольких DS в одном приложении. Оказалось, начиная с 4.2.1 jboss использует двухфазные транзакции для таких случаев.

Привет, народ!
Раз уж вы обсуждаете сервера приложений, то возможно сможете помочь с выбором сервера. Сейчас у нас стартуют 2 проекта, оба будут писаться одной командой, поэтому основные технологии будут одинаковыми, чтоб народ не разрывался.

Требования заказчика можно свести к следующим: скорость, удобство и минимальная итоговая цена. Поэтому решили по максимуму использовать дешёвые (по сути бесплатные   ) решения и для AS и для СУБД, тем более, что весь выбор предоставлен нам.

Сами проекты:
1. Небольшой корпоративный портал в масштабах 150 человек; немного узкоспециализированных расчетов, немного KPI, новостной раздел, а так же небольшой форум и голосовалка.

2. Портал уже в масштабах города, почти тоже самое, но умноженное в десятки тысяч раз, практически социальная сеть   

Из СУБД выбираем между MySQL и PostgreSQL. А на счет AS хочу с вами посоветоваться. Сам остановился между JBoss и GlassFish.

Основные требования: надежность, скорость и удобство использования (для самих разработчиков).

kedryz, я бы взял Glassfish. Особенно если вы собираетесь поднимать CI с интеграционными тестами на сервере и делать сборку через maven. По удобству работы и конфигурированию он, ИМХО, превосходит JBoss. По производительности ничего не скажу не про Glassfish, не про JBoss. Впрочем, еще многое зависит от технологий что вы будете использовать. Может вам и Tomcat хватит.

 

Чем же Glassfish лучше JBoss в плане CI?

Уж больно мне нравится maven плагин для Glassfish. Создание/удаление/старт/споп доменов, деплой/андеплой проектов делает легко и непринужденно. Конфигурация простая и логичная. Аналогов по функционалу и удобству для JBoss не встречал... я бы даже сказал что вообще удобных maven плагинов для JBoss не встречал (может плохо искал?).

Попробовал Jetty и Tomcat - не понравилось то, что приложения нельзя Redeploy'ить на "горячую". Сначал происходит undeploy, затем загрузка, а затем deploy. Это не удобно! Для Caucho Resin предлагают в доках использовать два веб-сервера...

Поэтому нашел для себя Glassfish: удобная панель администрирования и подходящая для меня функция Redeploy (они их делят на hot и cold).

AJetman, можно сделать redeploy просто заменив war-файл в папке webapps и он через несколько секунд сделает redeploy.

Как это сделать через maven? Дело в том, что плагины tomcat и cargo делают так, как я написал - сначала undeploy, затем загрузка и далее deploy.
К тому же, твоим способом придется сначала загрузить куда-то файл приложения, а затем его заменить в папке webapps.

Насчет maven не знаю. А так, просто замещается файл *.war в папке webapps.

Помогите понять, чем сервер приложений отличается от веб-сервера.
Насколько я понял, все сервера приложений строятся на основе веб-сервера.  Также сервер приложений осуществляет поддержку технологий из стандарта Java EE(веб-сервисы, JMS, EJB, JSP и так далее). Он позволяет развертывать веб-сервисы, веб-приложения. Но эти же функции может осуществлять веб-сервер. Тогда в чем же преимущество сервера приложений?
Поясню на примере. Допустим существует трехзвенное приложение. Клиент и сервер взаимодействуют при помощи веб-сервисов. Серверная часть представляет собой по сути консольное приложение, которое занимается кешированием, операциями доступа к данным и др. Самый простой способ развернуть серверную часть - "вручную" опубликовать сервисы при помощи EndPoint. А возможно ли запустить серверную часть приложения в сервере приложений, тем самым не публикуя веб-сервисы вручную?

Веб сервера как таковые не поддерживают JMS, EJB, JPA.

Caucho Resin + Apache для rewrite + nginx для статики 

Товарищи, а подскажите достоинства и недостатки Apache Tomcat и Oracle AS...

Ух ты, сколько зверюг экзотических понапоявлялось!.. ))

Опрос был начат 5.12.2008, но где-то ещё с февраля прошлого года BEA WebLogic прекратил своё существование по причине продажи компании BEA. Теперь это Oracle WebLogic Server. Исправьте, пожалуйста, в опросе.

Кстати, Oracle сейчас пытается всех пользователей Oracle AS перевести на Weblogic.

fixed. 

Jetty набирает обороты!
Поэтому все новое пишу на нём!
http://infoq.com
  

Не хватает SpringSource tc и SpringSource dm

Они, по-сути, на tomcat и они слишком "новы"...

Добавлено через 29 секунд
http://www.springsource.com/products/tcserver
http://www.springsource.com/products/dmserver

По сути - да, однако, по крайней мере, dm вполне можно выделить в отдельный продукт, так как tomcat - лишь часть этого сервера, как и в JBoss. В основном же это навороченный OSGi контейнер.

Добавлено через 49 секунд
Ах да, мой первоначальный вопрос снимается, так как сам уже разобрался 

Caucho Resin хвастаются в документации о своей производительности из-за наличия native-библиотек для каждой из платформ. Также у них есть уже rewrite модуль, насколько помню. 
Резонный вопрос: зачем Resin'у лишние сателлиты в виде Apache и Nginx?

Вот пишут, что глассфиш настройчивей джибосса... такой вопрос -
для одной специфической задачи (на JBoss-е) EJB и JMS доступны для вызова извне через servlet invoker, на том же порту что и вебсайт. А глассфиш так может с EJB работать? А с JMS может?

Это кастомное расширение JBoss, которое не входит в JavaEE спецификацию. Штука конечно интересная. Обычно доступ к бинам по HTTP делают через веб-сервисы (SOAP/RESTful) - это путь по которому с серверной частью могут взаимодействовать не только клиенты написанные на Java. Плюс использование такой фитчи JBoss-a гарантированно делает Ваше приложение непортируемым на другие сервера. И хотя в последнем существует редкая необходимость, такая особенность (портируемость) сама по себе является "хорошим тоном".

Я совершенно с вами согласен, однако стандарт - стандартом, а у каждого сервера приложений должен быть дополнительный набор "вкусняшек", дабы удовлетворять дополнительные капризы нужды пользователей.

И мне действительно интересно, можно ли на Glassfish-е настроить вызов EJB на одном порту совместно с web-сервером.

Лично я такого не встречал, наверное потому что этот функционал легко заменить альтернативным.

Эти "вкусняшки" превращаются в невообразимый геморрой, когда надо перенести приложение на другой сервер, их не имеющий. А весь код уже провязан "левыми" пакетами.

Перешили с Томкатов на Геронимо очень довольны. Позволяет создавать модульные аппликации без OSGI. Дикая экономия PermGen'a 

 Под "модульными аппликациями" подразумеваете использование GBeanов?

Нет, простые ворники без жарников в нутри (lib).

Использую Tomcat в основном. У Spring инфраструктура своя разворачивается, EJB  и прочее не нужны XD Spring гораздо удобнее тестировать, более предсказуем, сессионные бины нормальные...

Jboss и Glassfish уж больно какие-то толстые... У меня зачастую быстрее получается всё приложение собрать и передеплоить, чем разбираться с их косяками и глюками. И да, томкат стартует 2-3 секунды 0_О

Ещё я слежу за проектом Virgo (томкат с OSGI шиной и поддержкой нативной Spring), пробовал его поюзать, говна хлебнул... Не все библиотеки ещё готовы для использования в OSGI, манифесты дописывать...

Ну а про jetty чего вообще говорить, как соберёшь, так и будет работать. Широкий простор для извращений...

Apache Tomcat

А почему в списке нет Tomee? В конце концов это Tomcat с OpenEJB и CXF.

Oracle AS очень мало голосов... 

Вообще то удивительно, что аж почти 3 процента используют Oracle AS. Этот сервер наши индийские друзья перегрузили всякими надстройками, например PL/SQL шлюзами, Forms и Reports, а также Enterprise Manager'ом. А чтоб последний работал нужна база данных Oracle (для его репозитория).  В общем - вещь в себе! Удивительно, как он вообще работает. 
Однако я тут "наковырял" курс под  TomEE. Оказалось компактная штука, почти как Tomcat, но с EJB и проч. Хотелось узнать, использует ли его кто-либо. В нескольких западных блогах народ пишет, что "сползает" с GlassFish на него. А как у нас?

EJB  пользовал последний раз в 2006году , ни тогда ни счас не понимал зачем оно 
надо, сегодня есть spring + rest , если очень хочется и не жалко призводитеольности 
есть spring jpa data , для больших проектов где много однотипных запросов,
Хотя я лично противник маппингов и прочих фокусов с БД, 
Помню как целыми днями сидели не могли понять как это EJB  конфигурить,
на хрена мне RMI c коброй, и прочей хренью которую по пол дня конфигурить надо,
а при смени версии пол дня искать в гугле что не так, есть контроллер спокойно принимающий обьекты, есть пакет апачи для посылки поста и гета, если богатый клиент 
нужен, если по какой причине контролер не годиться - пишем сервлет,
или даем даем методу контролера request и response или session. И вот она сила AOP.
Что еще надо то? 

Jetty  - для легких вещей удобно , чаще всего как локалтный сервис ,
А спинговский томкат  воюбще в две минуты становиться  как JBOSS  если нужно,

Это сообщение отредактировал(а) sergioK1 - 21.9.2015, 23:39

С 2006 года много воды утекло. И нынче EJB можно грузить в WAR и конфигурить не сильно надо. Компоненты EJB хорошо специализированы под WEB приложения. Контроллер у меня самописный и работает удовлетворительно, для безопасности JAAS.    И в WEB слое в подпорках в виде Spring не нуждаюсь. А для бизнес слоя EJB вполне. Разработчики AOP и Spring рано или поздно захотят вообще избавиться от JavaEE. Оно все к тому идет. И возникает вопрос - куда идтить. Использовать ли универсальную открывалку всего и вся - Spring, или оставаться на платформе "назад в пампасы" и использовать фреймворки разных фирм для нужд низкого уровня. Вопрос ! 

Это сообщение отредактировал(а) mbasil - 2.10.2015, 15:53