Пользователь
0,0
рейтинг
12 февраля 2010 в 08:56

Разработка → Делаем простое веб приложение на Spring Framework MVC

Java*
image
В данной статье я хочу рассказать начинающим Java разработчикам, как написать простое веб приложение, используя популярный фреймворк Spring Framework.

При разрабокте приложения мы будем использовать утилиту Ant для автоматизации действий и изучим, как писать простой тест с помощью библиотеки JUnit. Весь код будем писать в Eclipse IDE.

Статья написана на основе первой части руководства «Introduction to Spring MVC». Вам достаточно иметь лишь общее представление о Spring, чтобы прочитать статью с пользой.

Так что милости просим :)


Для конфигурирования приложения в Spring можно использовать несколько спобов. Наиболее популярный путь – вынесение конфигурации в xml-файлы. Также это наиболее традиционный путь, который используется в фреймворке с первого релиза. С введением аннотаций в языке Java 5 появилась возможность настраивать фреймворк с помощью них (с версии 2.5). В данной статье мы будем использовать традиционный XML-стиль.

Необходимые инструменты


  • Java SDK 1.5,
  • Apache Tomcat 6,
  • Ant 1.7,
  • Junit 4.x,
  • Eclipse 3.

Важное замечание: при копировании кода замените кавычки «елочки» на обыкновенные. Это избавит Ваш код от ошибок :)

1. Создание структуры проекта


На установленный Eclipse поставим плагин Spring IDE. Создадим Spring-проект springapp, добавим папку war.
image

2. Создадим index.jsp


springapp/war/index.jsp
<html>
    <head>
        <title>Example :: Spring Application</title>
    </head>
    <body>
        <h1>Example - Spring Application</h1>
        <p>This is my test.</p>
    </body>
</html>


В папке war создадим WEB-INF, и разместим в ней web.xml.

springapp/war/WEB-INF/web.xml
<?xml version='1.0' encoding='UTF-8'?>
<web-app version='2.4'
    xmlns='java.sun.com/xml/ns/j2ee'
    xmlns:xsi='www.w3.org/2001/XMLSchema-instance'
    xsi:schemaLocation='http://java.sun.com/xml/ns/j2ee
    java.sun.com/xml/ns/j2ee/web-app_2_4.xsd>
    <welcome-file-list>
        <welcome-file>
            index.jsp
        </welcome-file>
    </welcome-file-list>
</web-app>


3. Деплоим приложение в Tomcat


Для развертывания приложения на сервере воспользуемся ant-скриптом (для начала работы с Ant достаточно прочитать заметку о нем в Википедии). Скрипт будет содержать цели для компиляции, построения и переноса приложения.

springapp/build.xml
<?xml version='1.0'?>
<project name='springapp' basedir='.' default='usage'>
    <property file='build.properties' />
    <property name='src.dir' value='src' />
    <property name='web.dir' value='war' />
    <property name='build.dir' value='${web.dir}/WEB-INF/classes' />
    <property name='name' value='springapp' />
    <path id='master-classpath'>
        <fileset dir='${web.dir}/WEB-INF/lib'>
            <include name='*.jar' />
        </fileset>
        <!-- We need the servlet API classes: -->
        <!-- * for Tomcat 5/6 use servlet-api.jar -->
        <!-- * for other app servers - check the docs -->
        <fileset dir='${appserver.lib}'>
            <include name='servlet*.jar' />
        </fileset>
        <pathelement path='${build.dir}' />
    </path>
    <target name='usage'>
        <echo message='' />
        <echo message='${name} build file' />
        <echo message='-----------------------------------' />
        <echo message='' />
        <echo message='Available targets are:' />
        <echo message='' />
        <echo message='build --> Build the application' />
        <echo message='deploy --> Deploy application as directory' />
        <echo message='deploywar --> Deploy application as a WAR file' />       
        <echo message='' />
    </target>
    <target name='build' description='Compile main source tree java files'>
        <mkdir dir='${build.dir}' />
        <javac destdir='${build.dir}' source='1.5' target='1.5' debug='true'
            deprecation='false' optimize='false' failonerror='true'>
            <src path='${src.dir}' />
            <classpath refid='master-classpath' />
        </javac>
    </target>
    <target name='deploy' depends='build' description='Deploy application'>
        <copy todir='${deploy.path}/${name}' preservelastmodified='true'>
            <fileset dir='${web.dir}'>
                <include name='**/*.*' />
            </fileset>
        </copy>
    </target>
    <target name='deploywar' depends='build'
        description='Deploy application as a WAR file'>
        <war destfile='${name}.war' webxml='${web.dir}/WEB-INF/web.xml'>
            <fileset dir='${web.dir}'>
                <include name='**/*.*' />
            </fileset>
        </war>
        <copy todir='${deploy.path}' preservelastmodified='true'>
            <fileset dir='.'>
                <include name='*.war' />
            </fileset>
        </copy>
    </target>
</project>


springapp/build.properties
# Ant properties for building the springapp
appserver.home=  C:/Program Files/Apache Software Foundation/Tomcat 6.0/

# for Tomcat 5 use $appserver.home}/server/lib
# for Tomcat 6 use $appserver.home}/lib
appserver.lib=${appserver.home}/lib
deploy.path=${appserver.home}/webapps
tomcat.manager.url=http://localhost:8080/manager
tomcat.manager.username=tomcat
tomcat.manager.password=s3cret


Установите корректно переменную appserver.home. У меня она указывает на C:/Program Files/Apache Software Foundation/Tomcat 6.0/.

Для создания пользователя Tomcat в файле appserver.home/conf/tomcat-users.xml сделайте запись:
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
   <role rolename="manager"/>
   <user username="tomcatpassword="s3cretroles="manager"/>
</tomcat-users>


Выполним build-скрипт: Контекстное меню файла build.xml > Run As > Ant Build > Выбрать цели build, deploy во вкладке Targets.

4. Проверим работоспособность приложения


Запустите Tomcat и откройте в браузере страницу localhost:8080/springapp/.
image

5. Скачиваем Spring Framework


Скачайте фреймворк, если вы ещё этого не сделали, и распакуйте его.

На этом настройка окружения закончена. Далее мы приступаем к конфигурированию самого приложения на Spring MVC.

6. Изменим web.xml в папке WEB-INF


Мы определим сервлет-дисптечер DispatcherServlet (также называемый Front Controller). Его цель – диспетчеризация поступающих запросов. Сделаем для этого сервлета маппинг. Мы решили все запросы с урлами вида '.htm' направлять на сервлет-дисптечер.

springapp/war/WEB-INF/web.xml
<?xml version="1.0encoding="UTF-8"?>
<web-app version="2.4xmlns="java.sun.com/xml/ns/j2ee"
    xmlns:xsi="www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="java.sun.com/xml/ns/j2ee
    java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
">
    <servlet>
        <servlet-name>springapp</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>springapp</servlet-name>
        <url-pattern>*.htm</url-pattern>
    </servlet-mapping>
    <welcome-file-list>
        <welcome-file>
            index.jsp
        </welcome-file>
    </welcome-file-list>
</web-app>


Создадим файл springapp-servlet.xml. Этот файл содержит описания бинов (Java-файлов), которые будет использовать DispatcherServlet. Иными словами файл определяет контекст сервлета (WebApplicationContext). По стандартному соглашению именования для Spring Web MVC, сервлет springapp будет иметь файл описания бинов с именем springapp-servlet.xml.

Добавим описание бина (bean entry) '/hello.htm' с классом springapp.web.HelloController. Эта запись определяет Контроллер, который будет использовать приложение для обслуживания запроса с урлом '/hello.htm'. Для маппинга урла на объект, что его будет обрабатывать, фреймворк Spring Web MVC использует класс, реализующий интерфейс HandlerMapping. По умолчанию для маппинга используется класс BeanNameUrlHandlerMapping.

В отличие от DispatcherServlet, HelloController ответственный за обработку запроса на конкретную страницу. Его также называют 'Page Controller'.

springapp/war/WEB-INF/springapp-servlet.xml
<?xml version="1.0" encoding="UTF-8"?><br/>
<beans xmlns="http://www.springframework.org/schema/beans"<br/>
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<br/>
	xsi:schemaLocation="http://www.springframework.org/schema/beans<br/>
    http://www.springframework.org/schema/beans/spring-beans-2.5.xsd"><br/>
	<!-- the application context definition for the springapp DispatcherServlet --><br/>
	<bean name="/hello.htm" class="springapp.web.HelloController" /><br/>
</beans>


7. Скопируем библиотеки в 'WEB-INF/lib'


Создадим директорию war/WEB-INF/lib и скопируем в нее необходимые библиотеки Spring:
  • spring.jar (из spring-framework-2.5/dist);
  • spring-webmvc.jar (из spring-framework-2.5/dist/modules);
  • commons-logging.jar (из spring-framework-2.5/lib/jakarta-commons);
  • junit-4.4.jar (из spring-framework-2.5/lib/ junit).


Добавим в Eclipse-проект необходимые библиотеки:
  • Контекстное меню проекта > Build Path > Configure Build Path > Add External JARs > 'war/WEB-INF/lib';
  • Контекстное меню проекта > Build Path > Configure Build Path > Add Library > Server Runtime > Tomcat.


8. Создадим Контроллер


Создадим Контроллер HelloController в пакете springapp.web.

springapp/src/springapp/web/HelloController.java
package springapp.web;

import org.springframework.web.servlet.mvc.Controller;
import org.springframework.web.servlet.ModelAndView;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import java.io.IOException;

public class HelloController implements Controller {
    protected final Log logger = LogFactory.getLog(getClass());

    public ModelAndView handleRequest(HttpServletRequest request,
            HttpServletResponse response) throws ServletException, IOException {
        logger.info(«Returning hello view»);
        return new ModelAndView(«hello.jsp»);
    }
}


Это очень упрощенная реализация Контроллера. Мы будем её расширять в дальнейшем, и также будем использовать готовые реализации контроллеров из фреймворка.

В модели MVC Контроллер обрабатывает запрос и возвращает Модель-и-Вид (ModelAndView) – в нашем случае страницу 'hello.jsp'. Модель, которую возвращает Контроллер, на самом деле разрешается через ViewResolver. Так как мы не указали явно ViewResolver, то будет использоваться резолвер по-умолчанию, который просто направляет запрос на адрес ресурса, указанный в Модели-и-Виде. В дальнейшем мы это изменим.

Также мы указали логгер, с помощью которого сможем проверить выполненную приложением работу. При использовании Tomcat журнал работы приложения мы сможем просмотреть в файле catalina.out, который можно найти по адресу ${Tomcat.home}/log.

9. Напишем тест для Контроллера


Тестирование – это один из самых важных этапов разработки сложных программных систем. Также это основополагающая практика при Agile software development. Многие считают, что наилучшее время написания тестов – втечение разработки, а не после. Так что, несмотря на простоту разработанного нами контроллера, мы напишем к нему тест.

Создадим тест HelloControllerTests, расширяющий класс TestCase из библиотеки Junit: New > Other > JUnit > JUnit Test Case.

Это модульный тест (unit test). Он проверяет, совпадает ли имя Вида, возвращаемое через handleRequest() с Видом, которое мы ожидаем: 'hello.jsp'.
image

springapp/src/springapp/web/HelloControllerTests.java
package springapp.web;

import org.springframework.web.servlet.ModelAndView;
import springapp.web.HelloController;
import static org.junit.Assert.*;
import org.junit.Test;

public class HelloControllerTests {

    @Test
    public void testHandleRequestView() throws Exception {
        HelloController controller = new HelloController();
        ModelAndView modelAndView = controller.handleRequest(nullnull);
        assertEquals(«hello.jsp», modelAndView.getViewName());
    }
}


Для запуска теста используем меню: Run > Run As > JUnit Test.
Результат выполнения теста:
image

Ещё одной практикой Agile-разработки является непрерывная интеграция (Continuous Integration). Хорошей идеей будет запуск тестов с каждым билдом (build), для того, чтобы быть уверенным в правильном поведении своего кода (в идеальном варианте тесты запускаются автоматически при каждом билде).

10. Создадим Вид


Настало время создать Вид. В нашем случае это будет JSP-страница hello.jsp.

springapp/war/hello.jsp
<html>
    <head>
        <title>Hello :: Spring Application</title>
    </head>
    <body>
        <h1>Hello - Spring Application</h1>
        <p>Greetings.</p>
    </body>
</html>


11. Скомпилируем и развернём приложение на сервере


Для файла build.xml добавим в Classpath библиотеку springapp\war\WEB-INF\lib\junit-4.4.jar, и выполним цели Build и Deploy (Контекстное меню файла build.xml > Run As > Ant Build… > вкладки Targets, Classpath).

12. Попробуем запустить приложение


В браузере наберем адрес http://localhost:8080/springapp/hello.htm.
image

13. Резюме


Давайте бегло просмотрим, что было сделано.
  1. Стартовая страница приложения – index.jsp. Служит для того, чтобы удостовериться в правильности установки окружения. Позднее мы ее изменим.
  2. Сервлет-диспетчер (DispatcherServlet или Front controller) с соответствующим файлом описания springapp-servlet.xml.
  3. Контроллер (Page controller) HelloController с базовой функциональностью – просто возвращает Модель-И-Вид. На данный момент Модель пустая. Полная реализация Модели будет сделана в дальнейшем.
  4. Модульный тест для контроллера HelloControllerTests, проверяющий, соответствует ли имя вида ожидаемому.
  5. Вид приложения – hello.jsp.


Ниже представлена структура проекта, которая должна быть после выполнения всех инструкций.
image

Готовый Eclipse-проект можно скачать здесь.

Спасибо за внимание. Желаю успехов!
Антон Щастный @schaan
карма
68,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (81)

  • +3
    jpg??
    • +3
      Спасибо, переделал в png.
  • +2
    Было бы неплохо добавить в приложение модель, раз уж это MVC:-)
    • 0
      К сожалению я успел проработать только первую часть руководства из шести. И мне она показалась достаточно законченной для того, чтобы показать её отдельно.

      Работа с моделью, БД рассматривается в мануале в следующих главах. Дойдут руки — напишу :)
  • +1
    начало хорошее.
    а вот дальше, когда надо изменить схему роутинга, использовать разные классы spring-овских контроллеров, добавить больше логики приложения и отображения, подключить БД…
    вот тут вопросов гораздо больше )
    думаю начинающим это очень поможет.
  • 0
    Тест у вас какой-то странный — использует junit 3 вместо junit 4.
    • 0
      Не пойму, где вы это увидели. Вроде 4.4
      • +4
        В junit 4 не надо расширять TestSuite, а тестовые методы помечаются аннотацией @Test. Eclipse с junit'ом может вас и поняли, но так поступать не принято.
        • 0
          *TestSuite->TestCase
        • 0
          Спасибо, исправил.
  • 0
    Это ж устаревшая модель, сейчас надо уже @Controller использоваться
    • 0
      Согласен.Может такой же пример только с полностью с аннотациями.
  • –2
    Щелкаем правой кнопкой на рабочем столе, создаём текстовый документ и пишум туда:



    Hello :: Spring Application


    Hello — Spring Application
    Greetings.



    переименовываем расширение в HTML.

    не вижу никакой разницы! тогда зачем платить больше? (с)
    • 0
      блин, теги удалились все. Прошу прощения :)
    • +3
      Spring и Java-фреймворки вообще — для написания строгих компилируемых приложений, отсюда и столько конфигурационных файлов и лишних, на ваш взгляд, телодвижений.
    • +4
      О! Пойдёте к нам генератором отчётов работать? Насколько в среднем вы быстрее FastReports отчёты пишете?
  • 0
    А вы не знаете, сколько в среднем простых запросов (например, генерация и вывод формы) выполняет в секнуду приложение на этом фреймворке? Есть какие-то цифры?
    • +1
      как напишите, столько и будет :)
      Spring создан для более сложных вещей, чем генерация банальных форм
      • 0
        Не знаете значит :)
        • +3
          Не уловил. Spring — архитектурное решение, и выигрыш тут в возможности расширения и прочих плюшках.

          Хотите быстродействия пишите сайты на C.
          • –1
            Я вас не понимаю. Если вам здесь не важна производительность, почему бы не взять Руби, с его приятным синтаксисом?

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

            (Если вы хотите привести в пример например ядро Линукса, как программу сложнее хэлловрлда, учтите, что оно нахоится в ужасном состоянии, код труднопонятен, там нет даже объектов и исключений, а трудоемкость и стоимость поддержки и разработки тоже высока).
            • +1
              Может для криворуких и сложно что-то написать на Си, но на нем написано громадное количество приложений и не только операционных систем, но и скажем, систем для сбора и предоставления финансовой информации.
            • 0
              Ну код линукса только с виду ужасен. А вообще системный софт не так уж и сложно писать по некоторым причинам. Например там код во многих местах регулярный по структуре, например драйвера.

              А что касается исключений и объектов… Не стоит оценивать язык по наличию/отсутствию фич. А то можно скзать, что руби низкоуровнев и неудобен, ведь в нем нету: вывода типов, паттерн матчинга, составлния списков, ленивых вычислений, макросов, транзакционной памяти, тредов, мультиметодов, алгебраических и рекурсивных типов и прочего-прочего-прочего…

              И да, быстрые веб приложения можно писать и на java и на ruby. Но на Ruby все же в большинстве случаев поудобнее=) Хотя некотрые вещи я бы написал все же на java…
          • +1
            Spring — это framework.

            C — язык программирования.

            Как их можно сравнивать?
            • 0
              Ну я про то, что в любом подходе важно соотношение быстродействия/удобства разработки/удобства поддержки и еще массы параметров.

              Написать вэбсервер для одной задачи можно на C и он будет быстрее других решений, которые заняли бы меньше времени на реализацию, обладали бы простотой поддержки и массой других преимуществ.

              С другой стороны используя фрэймворки и плюшки языков (допустим Руби и Рельсы) я быстро разработаю весь функционал, но работать будет медленней чем C-шный аналог.
              • 0
                Единственное, почему может проще поддерживать приложение написанное на (PHP, Ruby и прочим), так это то, что на них сейчас больше программистов вот и все.

                Фрэймворки и прочие плюшки написаны людьми, это я к тому, что все это можно написать и на Си, притом уже такие штуки есть.

                Можете спросить зачем?

                Можно даже взять, не Си, а PHP, фрэймоврков под него хоть отбавляй. Но зачем мне они? Если мне нужен только какой-то определенный функционал и я не хочу тащить огромный груз кода. Да, я потрачу немного времени на разработку, но зато для всех последующихих проектов у меня будет свой код, в котором не будет ничего лишнего.
      • 0
        Кода тестировали web приложение на java + spring + hibernate + tomcat + gwt
        Производительность измерялась в сотнях динамических страниц(точнее запросов с динамически формируемым ответом) в секунду — точнее сказать не могу, давно это было.
        Желез было 2х4 xeon 16G RAM

        зы: По ощущениям того тестирования я ожидал как минимум на порядок меньше.
    • 0
      Поздно, но всё же.
      На очень простых запросах (авторизация/acegi/ + выдача формы логина в случае облома)

      $ ab -t 10 -c 10 127.0.0.1:8080/anon/ | fgrep Requests
      Completed 5000 requests
      Completed 10000 requests
      Completed 15000 requests
      Finished 16500 requests
      Requests per second: 1649.89 [#/sec] (mean)

      это на P4-3200
      • 0
        Строчки, где «requests» с мелкой буквы — stderr, а не баг grep-а :)
      • 0
        Спасибо, примерный порядок величины понятен. По моим наблюдениям, примерно того же порядка цифры у PHP (у меня на Intel Core 2 Duo, 2×1.8 Ггц 130 запр/сек с Апачем и примерно 400-500 без). При использовании тяжелых фреймворков, понятно, отставание было бы больше.
  • +3
    static.springsource.org/spring-roo/reference/html/beginning.html
    Попробуйте это, 5 минут готовое приложение с моделями, связями по принципу MVC
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Ну для этого есть Grails (htttp://grails.org), который использует тот же Spring^ но конфигов минимум и пишутся они на Groovy. (В итоге даже полаконичние чем ваш пример на Питоне).

      Если интересно — я писал пост про этот фреймворк habrahabr.ru/blogs/java/75774/
    • 0
      ой, с этим я согласен, тонны xml кода!!!
    • +1
      А теперь навесьте сюда проверку по схеме, трансформацию в HTML и генерацию сущностей. Ну как, получилось?
      • НЛО прилетело и опубликовало эту надпись здесь
        • –1
          Загляните во внутренности вашего «замечательного» Yii и попробуйте не испугаться. Особенно, посмотрев как там сделаны события и «behaviours».
          • НЛО прилетело и опубликовало эту надпись здесь
            • –1
              Извартная реализация этих самых событий и behaviours через __get/__call/__set (это же неэффективно, и код получается запутанный, и выглядит извратно как-то).
        • 0
          Для трансформации xml в html я вообще не напишу ни строчки кода. А напишу XSLT шаблон. Сущности сгенерю при помощи опять же XSLT. При этом написав XSD схему я буду всегда уверен, что мне не подсунут кривой XML.
          В JSON нет такой мощи, извините.
          • 0
            А зачем конфиги в хтмл при помощи xlst превращать???
  • 0
    Спасибо, как раз хотел попробовать что-то новое.
    • НЛО прилетело и опубликовало эту надпись здесь
      • +4
        Высылайте.
        • +2
          И мне
  • 0
    Я, кстати, вчера выложил пример небольшого уже работающего приложения на Spring 3 и Hibernate. Если вам интересно, могу сюда ссылку дать.
    Само приложение — сырое, и кое что там даже и не работает, но дает понять как двигаться дальше.
    • 0
      давайте, оя интересно
  • +3
    много букв из ряда «как сделать», но почти нет букв на тему «зачем это делаем и почему делаем так».

    вот например, вы пишете:
    «Для развертывания приложения на сервере воспользуемся ant-скриптом (для начала работы с Ant достаточно прочитать заметку о нем в Википедии). Скрипт будет содержать цели для компиляции, построения и переноса приложения.» и приводите антовый скрипт, не поясняя зачем и что вы делаете и почему именно так. Ну разве начинающий поймёт? Он скопирует, вставит и будет работать, однако не врубится в суть и смысл.

    • +2
      Философия другая. Если человек уже начал изучать спринг — в его интересах самому это все разбирать. Он должен хотеть. Не хочет знать что такое ант — его проблема. Не хочет разбираться зачем ему этот скрипт — его проблема. Это все мое скромное мнение.
      А вот как раз таких туториалов, где все собрано step-by-step — очень мало.
    • 0
      Я согласен, что статься написана достаточно эскизно, опущен момент установки и Томката, и Eclipse, и плагина к Эклипсу. Согласитесь, тот, кому оно нужно, разберется с мелкими деталями, лентяя и талмуд не спасет :)
      • +1
        причём тут установка таких простых вещей? хотя несомненно, если при разработке важны какие-то пути, то нужно об этом сообщить.

        но дело не в установке, а в пояснении того, что делаете. Лентяй и по вашему мануалу ничего не изучит.

        Такое ощущение, что вы написали статью для отписки. «напишу так, а поймут или нет — не важно. кто захочет — разберётся.»
  • –2
    Такое «простое» веб-приложение отбивает всякое желание изучать Spring.
    • +1
      попробуйте простое приложение на GWT+Guice+Gin+MVP освоить, тогда точно все отвалится :)
    • +1
      Да уж) Я думал на зенде как-то многословно… А тут такое)))
  • +1
    Статья из разряда, как запустить HelloWorld!
    И использование аннотаций, как мне кажется, намного лучше показывает красоту spring mvc.
    • +2
      + Может сразу будете использовать Maven?!
    • –3
      нда, это яркий пример, что если сильно хочется, то красоту можно увидеть и на помойке :))
  • –3
    Не хочу поднимать флейм, но зачем все это? Неужели кто-то в здравом уме будет все это использовать, писать многокилометровые XML-и только ради того, чтобы прикоснуться к миру J2EE? Какая экономическая целесообразность? Ведь намного проще и быстрее (а значит и выгоднее) использовать легковесные фреймворки — тот же Grails (если уж так хочется джаву), RoR, Django и т.п.

    Мне просто реально интересно. Знаю, что люди используют, но не понимаю, почему. Скажу сразу — Spring пытался использовать, но дальше того примера, который был приведен, особо и не ушел — мне мое время жалко, и я понял, что это не мое.
    • –3
      это простой способ поднять карму и не надо тут искать глубоких причин
      • 0
        мелковато и толстовато
    • +1
      Согласен, J2EE тяжеловесная штуковина. Но я на этом пишу. Работа такая. А теперь вопрос: Ты начинаешь писать свой проект. Знаешь только J2EE, тебе быстрее писать на то, что ты знаешь, или с нуля начинать учить django и т.д.?
      • 0
        Гы, быстрее выучить django и потом быстренько сделать. Пример из жизни — мне надо было написать одно сетевое приложение. Я очень хорошо знал дотнет, и мог быстро на нем все слабать (скажем за месяц). Но я решил сделать приложение кроссплатформенным, поэтому скрипя сердце взялся за Python. В итоге я за две недели (первые 3-4 дня на изучение питона) написал это приложение. Почему? Потому что на нем писать быстрее, проще, и есть удобные и легкие в использовании библиотеки.

        Думаю, аналогия понятна — лучше день потратить, а потом долететь. На J2EE ну реально все очень долго разрабатывать (если конечно, это не однотипные проекты с наработками, которые просто перекидываются из проекта в проект). Хотя саму джаву я уважаю, но веб-разработка под ней — это тихий ужас (если, конечно, не использовать легковесные фреймворки).
    • +3
      Я думаю, если человек после прочтения статьи попробует Spring и сделает вывод использовать Джанго, то это тоже результат. Всё познаётся в сравнении.
    • +1
      Когда будете писать кластерное решение с распределенными транзакциями — тогда и поймёте, что легковесные фреймворки можно использовать не везде.
      • 0
        Вот это я и хотел услышать. Действительно, с распределенными транзакциями я не работал, и те фреймворки, которые я использую, их не поддерживают (насколько я знаю).

        А вот насчет кластерных решений не понял. Точнее, я понимаю, что это звучит круто, но без уточнения непонятно о чем речь. Кластер чего? Серверов приложений? Чем обычный load balancer мешает это организовать?
    • +1
      Кстати, Капитан Очевидность сообщает, что Спринг в общем-то никакого отношения к JavaEE не имеет.
    • 0
      Автор просто ступил и написал про использование устаревшей версии фреймворка, устаревшим подходом. На самом деле в новых версиях все менее убого.
  • +1
    сложноватый «привет мир» х_Х"
  • 0
    Кстати, а вы не в курсе как связать GWT со спрингом? А то у нас никак не получается, столько всего попробовали, и не работает, хоть ты тресни. Может у вас есть какой-то работающий рецепт?
    • 0
      Здесь достаточно подробно описан самый прямолинейный вариант.
      technophiliac.wordpress.com/2008/08/24/giving-gwt-a-spring-in-its-step/
      • 0
        Спасибо за ответ.
        Я, кстати, видел этот туториал. Не получилось. Почему? Потому что GWT уже давно не 1.5beta, Spring у нас уже третий стоит, соответсвенно все там не так и не работает.
        Один вариант вроде как завели, но разрабатывать в нем — ужас, потому что при изминении кода идет перекомпиляция всего проекта.
        Наверно будем ждать времени, когда google сделает интеграцию с maven и/или spring'ом куда более прозрачной.
        • 0
          Не пробовал на третьем, но по идее там все примерно так-же должно быть. Главное это контроллер/резолвер который знает на какой бин какой запрос перебрасывать. Один раз помучаться и работает до следующего major release gwt или spring :)
          • 0
            Да я ж и говорю, вроде как завели, и оно даже в hosted mode работает, но сделал небольшое изминение в ОДНОМ файле — жди пока проект пересоберется. Для разработки же это ну никуда не годится.
            • 0
              Дык для разработки нужно использовать develop mode ;)
              Хостед — да, собирает, компилирует java в javascript, создает пермутации для каждого браузера…
              А в девелоп-режиме клиентская часть — на лету.
              • 0
                Два с половиной года прошло! Я уже на джаве давно не пишу, эх…
  • 0
    Пост не очень. Сам так когда-то учил спринг. Не правильно все это.

    * Используйте maven
    * Используйте аннотации

    Выглядеть это будет примерно так:
    1) mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-webapp -DgroupId=com.mycompany.app -DartifactId=myproject
    2) В зависимостях прописываем нужные артефакты, которые найдем на mvnrepository.com.
    3) Прописать в web.xml сервлет и context-listener
    4) В конеткст файле прописать context:annotation-config и context:component-scan.
    5) Там же объявить viewResolver
    6) Выполнить mvn eclipse:eclipse и открыть проект в eclipse.
    5) Создать класс-контроллер с аннотацией @Controller
    6) Создать jsp-шку
    7) Закрыть эклипс и написать в консоли mvn clean jetty:run
    8) Открыть браузер и радоваться, что не так уж и много телодвижений нужно было сделать

    Но! вместо всего этого можно и так: поставить Spring Tool Suite и создать шаблонный проект. Все действия 1-6 сделают за нас=) Нам останется только mvn clean jetty:run

    И самое главное.
    * По возможности не используйте спринг. Он был как легковесная замена java ee. Но он сильно распух. Теперь я использую google guice.
    • 0
      Спасибо за комментарий. С мавеном и аннотациями напишу уже в следующем посте.
      PS И насколько я понял, ещё не все разработчики бросились переходить на мавен.
      • 0
        Да, с мавеном не все хорошо. Инертность мышления… В итоге некоторые плагины к нему заброшеные или глючные. Раньше использовал ant, но как попробовал maven, то понял, что никогда не вернусь на ant, даже при всех недостатках maven. Так что определенно рекомендую.
    • 0
      Не могли бы вы расширить свой комментарий и оформить в виде отдельного поста? Думаю, не я один был бы благодарен :)

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