По следам поста «Быстрая разработка веб-приложений на Java»

image
Мотивом написания данной статьи послужило прочтение поста «Быстрая разработка веб-приложений на Java» и небольшой когнитивный диссонанс, возникший после прочтения и вопрос, который продолжает попрежднему мучать меня — Зачем такие сложности? Если есть WTP!

Далее я расскажу как я веду разработку под tomcat.

Локальная разработка



Для локальной разработки я использую WTP, это намного удобней постоянных запусков/перезапусков проекта, все обновления подхватываются на лету. И готов поспорить с asolntsev на тему тяжести плагина.

Настраивается все очень просто. В Eclipse File->New->Other...->Server, далее выбираем требуемый сервер и пусь, где локально установлена инстанция сервера (Например tomcat) и жмем Finish. Теперь во View «Servers» появился новый сервер, который можно запускать и на который можно публиковать веб-проекты.

Фактически Eclipse используется установленную инстанцию, но конфиги для работы берет из папки .metadata\.plugins\org.eclipse.wst.server.core\tmp[0]\, при желании их можно править напрямую.

Если проект maven — тоже ничего сложного в этом нет. Ставим plugin m2eclipse, добавляем plugin’s репозитарий m2e-extras и доустанавливаем «Maven Integration for WTP», после чего появляется возможность публиковать mvn веб-проекты в WTP.

Достоинства
  • Не нужно перезапускать проект — изменения подхватываются на лету
  • Избавляемся от ошибок связанных с особенностями контейнера
  • Логи отображаются в консоли в Eclipse

Недостатки
  • Иногда проект клинит и не обновляется — лечится правой кнопкой на сервере «Clean...»


Удаленная разработка



Когда проект по моему мнению готов, я выкладываю его на тестовый сервер запуском task в ant, для этого придется прописать в build-е пути к catalina-ant.jar, jasper-compiler.jar, jasper-runtime.jar, servlet-api.jar, commons-logging.jar. Почитать про настройку деплоя через ant можно например тут .


<taskdef resource="org/apache/catalina/ant/catalina.tasks" classpathref="tomcat.classpath" />
<target name="deploy_test" depends="war" description="Create a war file">
<undeploy url="${tomcat.node1}/manager" username="admin" password="admin" path="/test"  failonerror="no"/>
<undeploy url="${tomcat.node2}/manager" username="admin" password="admin" path="/test"  failonerror="no"/>
<deploy url="${tomcat.node1}/manager" username="admin" password="admin" path="/test" war="${distrib}" />
<deploy url="${tomcat.node2}/manager" username="admin" password="admin" path="/test" war="${distrib}" />
</target>

Все — обновленная версия проекта ушла на сервер (или на несколько серверов).

Достоинства
  • Простота использования
  • Надежность обновления

Недостатки
  • Перед публикацие требуется переcборка war


Заключение



Данные методы не претендуют на универсальность, но я не сталкивался c задачами, когда было бы невозможно использовать данную схему работы. Хотелось бы также услышать ваше мнение по поводу данных способов работ.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 38
  • –1
    Неплохое решение, но для Java разработчиков есть очень удобный playframework, который является новым шагом в мире Java framework'ов, думаю он заслуживает внимание.
    • 0
      Он прикольный, но это вещь в себе, новая платформа для разработки. С таким же успехом можно посоветовать, например, писать на Django.
      • 0
        речь идет о быстрой разработки веб приложений на Джава, и это единственный фреймворк который позволит это делать.
        • –1
          Ни одного, ни малейшего, даже в названиях, отличия от Spring MVC. Причем еще старой версии, 2.х, которой в обед сто лет. При этом фреймворк свежий, а значит плохо отлаженный и с минимальной базой пользовательского опыта работы с ним (и решения его проблем) в Сети. Быстро на нем только заглавную страничку налабать можно будет, а после первой же проблемы начнутся… проблемы.
          • 0
            с чего вы взяли?
            • 0
              С чего я взял что? Что нет отличий? Полистал фреймворк. Он типовой, каких десятки — в веб-разработке сейчас новое слово довольно сложно сказать. Что начнутся проблемы? Это аксиома, я на самом деле не хочу говорить об этом. Что эти проблемы сложнее будет решать? Решение любой нетиповой (не разобранной в туториале) проблемы сейчас находится одним из двух способов: 1) в книжке "… in Action" издательства O'Reilly, которой нет; и 2) в Сети, и тогда количество решенных проблем (и скорость нахождения решения) напрямую зависят от возраста фреймворка. Которым данный экземпляр похвастаться тоже не может.

              Детально: в основе у нас что? MVC, классы контроллеров. На морде у нас что? Темплейтный движок «мы не жсп». К базе мы как? По javax.persistance, как все. Валидируемся мы как? Аннотациями JSR-303, причем клиентскую валидацию мы не умеем (как все, однако для того же спринга способ прикрутить клиентскую валидацию по тем же JSR-303 есть — потому что возраст системы способствует; а для этого фреймворка?).

              Я не говорю, что фреймворк плохой. Я просто говорю, что он такой же. Как все. Со своими проблемами, которые он специально затачивался, чтобы решать, и со своими уникальными проблемами, которых нет у кого-то еще. Как обычно.
              • 0
                Разработка на нем ведется в разы быстрее чем на спринге.
                Он взял все самое лучшее из рельсов. А ваши проблемы в любом фреймворке есть.
                • –1
                  > Разработка на нем ведется в разы быстрее чем на спринге.
                  Ну вот как, как она там может вестись быстрее, если в нем точно такие же: а) ORM-слой, б) бизнес-логика, в) темплейты вьюх? В чем разница, может, я упустил что-то?

                  > А ваши проблемы в любом фреймворке есть.
                  Ну так я об этом и говорю.
                  • 0
                    Вы не видели кажется этот фреймворк в действии.
                    Да он использует почти все тоже самое, но обертки которые там сделаны, увеличивают простоту кода и скорость разработки. Ну и тем самым облегчает жизнь разработчику.
                    • 0
                      Вы какими-то очень общими фразами говорите. «Обертки, которые там», «увеличивают простоту и скорость», «разработка в разы быстрее», «лучшее из рельсов» (этим только ленивый кстати не кичится нынче). Я же изучил референс по этому фреймворку, и никакой магии там не обнаружил, все точно такое же, более того: я могу при необходимости глава-в-главу сопоставить, со ссылками, референсы по spring и по play. Но я действительно на практике с ним не работал, и пытаюсь понять, стоит ли овчинка изучения. И вполне допускаю, что вижу среди всего массива данных об этом фреймворке только знакомое, оттого у меня такое, возможно неверное, впечатление о нем. Так давайте говорить предметно, какие конкретные фичи улучшают производительность программиста в play? Какие-то может быть утилити классы, или инструменты, или архитектурные решения вы конкретные можете назвать?
                      • 0
                        как минимум там есть crud для классов моделей.
                          • 0
                            ушел со спринга до того, как это появилось. Это что генератор кода чтоли?
                            • 0
                              Угум. Ну, в том числе. Это та самая «умная» составляющая из рельсов, которая пытается облегчить рутину. Но Roo уже несколько лет, если вы пользовались Spring старых версий, до ну хотя бы 2.5, то я могу понять причину наших разногласий. :)
                              • 0
                                последняя версия с которой я работал была 2.5, но 3.0 я смотрел и ничего кроме аннотаций не видел. Но я все такие о фреймворке, а не о генераторе. Такой генератор можно для всего сделать, но если смотреть чисто на фреймворк.
                                • –1
                                  … ииии да. Согласен.
          • +1
            Я хочу акцентировать внимание на том, что приложения разрабатываются по большому счету не то, что на языке, а на платформе. Сам же язык — штука второстепенная.
      • +1
        А если проект Ant + Ivy + IDEA, добиться запуска прямо из IDE не получается из за сотен внешних зависимостей?
        • 0
          На счет Ivy, не знаю не пробовал

          Но использую вариант с Maven — все зависимости нормально подтягиваются из репозитариев и проект запускается под wtp.
          • 0
            Конечно получается. Есть плагин IvyIDEA, который умеет подкачивать все зависимости и добавлять в classpath проекта.
          • +6
            >я использую WTF

            Точно WTF? Или все-таки WTP? :)
          • +1
            >Все обновления подхватываются на лету

            Это чисто маркетинговый ход. В любом фреймворке с таким механизмом есть заранее оговоренные ограничения и точно не все обновления подхватываются на лету.
            • +1
              +1 за PlayFramework. Особенно хорош в связке со Scala
              • –1
                На Scala есть знаменитый Lift. Впринципе, разрабатывать еще быстрее, чем на Play, если ты разработчик этого самого Lift )) Для новичков же настолько неудобоварим, что заморачиваться даже не стоит. Как впрочем и практически любая либа на scala, пестрящая закорючками и DSL-ями.
              • +2
                Вы забыли про самый основной недостаток — это все под Eclipse. Очень много людей использует Netbeans, еще, наверное, больше IDEA. А еще в одной команде могут быть разработчики на разных IDE. Поэтому предыдущее решение мне понравилось больше, только было бы здорово, если бы был пример конфига для maven.
                • 0
                  Я бы даже больше сказал — это основной плюс.
                  С использование различный сред в команде это никак не связано, это дело каждого где и как вести разработку — я лишь делюсь опытом.
                • +1
                  Я не до конца понял: вот добавил я модельный класс, DAO, какой-нибудь сервис, контроллер и шаблон — после этого я смогу в браузере нажать F5 и все заработает без какого-либо редеплоймента? Браузер отобразит новую страницу за секунду или менее?
                  • 0
                    Будет redeployment. Изменения на лету подхватываются только в jsp. Все что лежит в классах требует редеплоймента и рестарта сервера.
                    • 0
                      Совсем нет прелесть wtp в том что перезапускать сервер не надо, а редиплой произойдет на лету
                      • 0
                        Для spring и сервлетов? Что-то не заметил.
                        • 0
                          Вы попробуйте на сервлетах, попробуете потом обсудим :-)
                          • 0
                            Я вообще каждый день пробую и не поверите оно редеплоит класс. А в случае spring надо еще и весь контекст перезагрузить.
                            • 0
                              аа… вот вы к чему — согласен, редиплоится класс, но ведь это все происходит автоматически и не надо делать рестарт сервера или жмякать кнопку Publish (если вы конечно не отключили автопубликацию) — удобно же, пока переключаешься на браузер у тебя уже автоматом новая версия на локальном tomcat-е :-)

                              со спрингом честно не экспериментировал — не довелось, но все сервлеты, mb/dao классы редиплоятся на ура :-)
                              • 0
                                В случае spring это приводит к долгому redeploy, если конечно включен дебаг :)
                  • 0
                    В Tapestry можно и без плагина все плюшки получить, в нём даже можно java классы на лету менять без redeploy, единственное когда нужен redeploy это если вы поменяли Entity классы.
                    • 0
                      Спорить не буду.
                      Если у вас это работает и вам это удобно использовать — используйте на здоровье.
                      Добавил к WTP ссылку на эту статью.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.