странно, почему вы думаете, что Jetty тормознутый — его очень многие используют, и как раз потому, что достаточно быстрый и расширяемый, с другой стороны небольшой. Уж по крайней мере по сравнению с приводимыми Tomcat и jBoss
Да не думаю я так, просто часто слышал подобные высказывания.
Я это не подтверждаю и не опровергаю, я говорю, что в данном контексте это неважно.
Jetty используют в tankionline.com для выдачи статичного контента (конфигов, в частности).
Так что не думаю, что такой уж тормознутый, учитывая специфику указанного ресурса и посещаемость.
Статика отдается nginx. Конфиги отдаются jetty, но кешируются тоже nginx.
Jetty умер бы на таком трафике.
Да не думаю я так. Мне просто доводилось слышать подобные высказывания.
Я их не подтверждаю и не опровергаю, я говорю, что в данном контексте это неважно.
>Контейнер Jetty уступает в производительности Tomcat, JBoss, Resin и др.
>Контейнер Jetty нестабилен / иногда грохается

Извините за оффтоп, но откуда вы это взяли? :) У нас Jetty использует в продакшне под нагрузкой. Все устраивает.
И не только у вас.
Google App Engine использует Jetty.
Единственный способ разрабатывать быстро веб приложения на JAVA это использование PLAY! framework.
Holy war? Способы бывают разные.
Tapestry 5 неплохой современный framework. И кстати, умеет самостоятельно перезагружать классы приложения.
вы использовали Play? из коробки CRUD интерфейс, авторизация?? и много другое
А что OSGi. OSGi тоже будет либо с jetty либо с tomcat бандлом. Ну или с чем то еще.
У меня один раз получилось настроить Eclipse WTP для hot redeploy. Но как то он жил своей жизнью, при смене лунной фазы все переставало работать.
А почему вы не приводите в пример maven, в частности jetty-maven-plugin? Всякие IDE-зависимые вещи, как показывает опыт, очень сильно мешают в переспективе — настройка environment'а слишком затягивается для новых сотрудников или после восстановление системы, плюс всякие несовместимости плагинов и т.п.
Да, есть и такой способ. Кстати, не только Maven — например, в Gradle это очень удобно сделано. Добавлю.

Ну да, этим Launcher и хорош, что не зависит от IDE.
Gradle — это, емнип, для grails. Поэтому не очень для дженеричной java. А Launcher хорош, но имхо, maven он более православный путь в том смысле, что уже есть велосипед :)
Ничего подобного, Gradle — инструмент для сборки любых проектов, и в частности, для Java он прекрасно подходит. Например, проект Hibernate перешёл на него год или два назад. Мы тоже его используем, очень удобно.

Если ты запускаешь приложение из Maven, как его дебажить? Есть, конечно, remote debug, но ведь его ещё надо настроить. Запускать дебаг одной кнопкой по-любому проще.
Про Gradle, ok. Не знал.

На счет дебага — эмебеддед jetty плагин запускается в том же процессе, что и мавен. Соответственно, когда ты запускаешь мавен таску из IDE в дебаге, соответственно он и код дебажит, поэтому все одной кнопкой.
в силу особенностей апп использую Red5 server но процедура запуска у меня аналогичная.
Добавлю еще что самый-самый правильный способ разработки, это когда результат проверяется юнит-тестами. Во-первых юнит-тесты обычно быстро запускаются из IDE, так как IDE и так совершает инкрементальную компиляцию + проверка работоспособности автоматизируется и происходит быстрее.
UI юнит-тестами нормально не покроешь — все равно глазами пробежаться придется
Вот по этому я люблю разделять разработку логики и UI. Вначале сервисы можно тестами покрывать. А UI да, ручками протыкивать.
в список альтернатив можно было ещё grails добавить
Скажи пожалуйста, а c приложениеями, которые активно используют CDI, JPA, JSF и прочие JEE оно наверно не взлетит?
С JPA и JSF взлетит спокойно, почему нет.
Насчёт CDI сказать не могу, не пробовал. Насчёт остальных JEE сложно сказать, надо рассматривать каждый в отдельности.
значит для каждой используемой плюшки нужно будет просто подсовывать нужные jar-файлы, так?
Ну да, видимо, так.
вся эта кухня с Jetty — просто жестко связываетя, то что Sun сознательно разделила. Вы бы попробовали тот же JPA на нормальном JEE контейнере — совсем другая песня, а с Jetty — тот-еще гемор с конфигами.
JRebel вам в помощь. Правда, он не бесплатный.
Мы пользуемся Sysdeo (для Tomcat) для Eclipse, который позволяет совместить контекст томката и проекта, потому не нужно собирание war-файла и подкладывание его контейнеру, всякий css, html и прочий js правится сразу, на горячую. В большинстве случаев работает hot replace.
Да, его я тоже пробовал. В общем, хорошая штука, делает примерно то же самое.

Но мне кажется, он требует больше телодвижений. И Томкат надо поставить, и какой-то новый «tomcat project» создать… А что, если я не хочу новый проект создавать? И структура этого проекта должна быть строго определённая…
И ещё он меняет сам Томкат (server.xml). В общем, хорошо, но можно проще.
Да, существующую кодовую базу сложно привести в соответствие с требованиями, накладываемыми плагином. Но можно, и делалось. server.xml насколько я помню не меняется, добавляется только описание нового контекста, но я могу ошибаться. В любом случае — это томкат локальный, если что — его не жалко. Ну и я написал по поводу Sysdeo наверное больше потому, что по-хорошему его бы тоже добавить в список альтернативных решений. Оно все же лучше, когда используется один и тот же контейнер на машине разработчика, и на сервере.
НЛО прилетело и оставило эту надпись здесь.
Не знаю, важно ли, но с седьмой версии Jetty названия пакетов и классов были поменяны с org.mortbay.jetty.* на org.eclipse.jetty.* — подробнее в Eclipse Wiki.
Соответственно, ваш код с более новыми версиями Jetty работать не будет (что, правда, пока не так сильно важно, поскольку и 6-ая и 7-ая версия поддерживаются; впрочем, сами разработчики Jetty рекомендуют для новых проектов использовать седьмую версию).
А я Spring source tool suite использую — их навороченный томкэт умеет редеплоить при сохранении файлов.
Если в проекте используется Maven, то все проблемы решаются Embeded Jetty плагином.
Eclispe и Idea умеют запускать MVN-задачи, а редеплоится Jetty будет автоматом в таком режиме (от этого правда больше негатива, чем позитива).
Спасибо за статью. Настроил все так же как вы и описывали. Однако приложение почему-то не подхватывает автоматически свежескомпиллированный код. Пользуюсь Intellij Idea (создал линк с out к WEB-INF/classes), работаю с javax.ws + org.restlet. Нужно ли мне что-то еще настраивать? Или это спицифика выбранных фреймворков?
Кстати, статика отдается нормально, проверил скомпилленные классы — меняется время последнего изменения, но все равно не подхватывается
Нет, ничего настраивать не надо. IDEA умеет сама подхватывать свежескомпилированные классы. Правда, есть ограничение, накладываемой явой: перекомпилированный класс подхватится, только если изменения внутри тела метода. А если изменился API (т.е. сигнатура метода, имя класса), то не подхватится. Но в обоих случаях IDEA явно говорит об этом пользователю: после компиляции в левом нижнем углу вслывает окошечко с надписью a'la «classes reloaded» или «classes could not be reloaded».

Кстити, в IDEA эту функциональность можно принудительно отключить. Может, она у вас отключена?
Хм. Заработало только в режими дебага, но в обычном режиме не работает. Но это меня устраивает. Спасибо за труды
IDEA c Tomcat подхватывает изменения css/html на лету, если запускаться как Tomcat Server local или через tomcat7-maven-plugin.
Из IDEA я не пробовал запускать Tomcat. Пробовал из Eclipse (точнее, MyEclipse). Во-первых, интерфейс был очень сложным. А во-вторых, скорость ужасающая. По каждому чиху MyEclipse копировала все статические ресурсы и java-классы в tomcat. Приложение большое, ресурсов было много — копирование тормозило жутко.
Правка: подхватывает если
1. деплоить не war а war exploded
2. в окне Debug у Server Deployment нажата кнопка Update Resources on Frame Deactivation
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.