Вышел Spring Framework 3.1 GA

    image
    Наконец-то, после достаточно большого времени бет и релиз-кандидатов вышла новая стабильная версия замечательного Spring Framework. Английский анонс тут, а по-русски — под катом

    Итак — из вкусного (приглянувшегося мне):
    * Механизм кеширования (про который я уже как -то писал);
    * Поддержка профилей (возможность легко переключать конфигурацию на разные environment-ы)

    а так же:

    * Поддержка Servlet 3.0 и конфигурация Spring Framework без использования web.xml (хотя не думаю что прям сейчас много кто использует это)
    * Улучшения в REST
    * Улучшения в поддержке JPA (обещано что можно будет поднимать JPA без persistence.xml) и поддержка Hibernate 4.0
    * Поддержка новых фич Java 7 (честно скажу — еще не использую — потому сказать каких именно и в чем прикол мне сложно).

    Хороший эволюционный шаг вперед, спасибо команде SpringSource за новый релиз!
    Поделиться публикацией

    Похожие публикации

    Комментарии 26
      +2
      Подскажите, в Spring MVC есть механизм генерации урлов? Что нибудь похожее на @@{Controller.action(var1, var2)} в Play Framework?
        0
        Нет, такого там нет.
        Есть стандартный c:url, или spring:url, но они к контроллеру не привязываются. Хотя IDE, типа Idea резолвит и можно перейти к коду контрлллера.
        +1
        Не знаком с Play Framework, но в Spring есть аннотации для работы с URL.
        @RequestMapping(value = "/edit", method = RequestMethod.GET)
        public String edit(Model model, @RequestParam(value = "text", required = true) String text) {
          ...
        }
          0
          Аннотации это хорошо, но как генерировать url-ы во view для контроллеров и их методов?
            0
            В jsp можно так:
            <spring:url value="/url/path/{variableName}">
               <spring:param name="variableName" value="more than JSTL c:url" />
             </spring:url>
            

            static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/servlet/tags/UrlTag.html

            Скажите конкретней что вы имеете ввиду под «как генерировать url-ы во view для контроллеров и их методов», я вам отвечу. Play не щупал, если напишите что там хитрое выдумали, попробую сказать как это сделать в спринге.
              0
              Смотрите, есть у меня контроллер «Document» и у него есть метод «show», который я через аннотации привязываю к урлу /document/show/{id}/

              Как мне во вьюшках генерировать этот урл по имени контроллера и метода? В Play это делается следующим тагом в View шаблоне:

              @{ Document.show(12) } и на выходе я получу /document/show/12

              И если я в аннотации поменяю урл, то он изменится во всех View. Можно ли делать подобное в Spring?
                0
                Насколько мне известно — нет, такой функции в Spring MVC пока нет и приходится изобретать свои костыли. С другой стороны, в Grails, который сделан на основе Spring MVC, такое есть. Возможно, это можно портировать.
                  0
                  Да, такой функциональности в спринге нет. Если очень хочется можно написать свою библиотеку тегов, взяв за основу что-то такое github.com/bazhenov/spring-url-builder

                  Лично я не вижу необходимости в такой фиче, поясню почему. Как часто вы меняете URL? Допустим часто. Но что происходит чаще — изменение path в URL или добавление каки-либо дополнительных query параметров? У меня такое ощущение, что параметры изменяются чаще чем путь. А в таком случае вам придетсе все-равно найти все точки формирования URL и прописать в них новый/измененный параметр. Таким образом возможности предлагаемого вами способа не превосходят (не сильно превосходят) возможностей встренного тега <spring:url> и не дадут ощутимого выйгрыша.
                    0
                    Просто хардкодить что-либо это вообще не очень хорошая практика. В том числе и URL.
                      0
                      Может тогда вынесем url и из RequestMapping — @RequestMapping(value=UrlConstants.EDIT_DOCUMENT)?

                        0
                        Но во View-то оно останется при таком подходе. О чем собственно kai и писал
                          0
                          Можно конечно и во View вывести константу, но все же тогда запись вида @{ Document.show(12) } выглядит лаконичнее
                        0
                        Я хочу сказать что у вас при добавлении параметра все равно надо везде его дописать
                          0
                          У меня (в Play) в режиме разработки выведется няшное сообщение об ошибке во View, т.к. не будет найден метод с соответствующей сигнатурой. Что удобно и к этому привыкаешь.
                            0
                            Но увидите вы это сообщение только когда дернете УРЛ. Чтобы добавить параметр, все равно придется найти все места во вьюхах, где УРЛ формируется
                              0
                              Да, я понимаю. Но так проще искать проблемные места после изменений в коде. Ну и генерация урлов помогает, когда меняешь их в коде. Не нужно по шаблонам бегать.
                        0
                        1. На этапе разработки я частенько меняю URLы
                        2. При изменении сигнатуры метода в Play я получаю явную ошибку во View, т.к. при обработке шаблона не будет найден метод с необходимой сигнатурой.

                        Это удобно. Поэтому хочется понять, есть ли такая штука в Spring.
                          0
                          Я выше уже ответил, такого нет.
                          0
                          А мне как раз нравится Spring MVC — за то что он не прячет детали коммуникации (собственно сам протокол http, используемые урлы и передачу параметров) — а просто упрощает их обработку.
                          Объясню на примере — долго использовал JSF (с RichFaces) — там вообще все в шоколаде — пишешь #{controlled.callSomeMethod()} — и не паришься — как там это все передается, какие урлы регерятся, как параметры передаются, как они попадают в контроллер — вообщем все происходит автоматом.
                          Только когда у тебя страница вдруг начинает весить под 2 метра — потому что во всех урлах передается state, либо когда начинаются танцы с бубном, потому что надо SEO Friendly URL-ы, либо когда вдруг сильно упираешься в перфоманс…
                          SpringMVC — по сути дела практически голый JSP API — просто с набором вещей которые упрощают его использование — в итоге ты всегда контролируешь что и как работает.
                            0
                            У SpringMVC (как и у Struts2, например) есть своя ниша — это сайты, для которых нужен этот контроль над request-response (например — полностью динамические страницы, без определенной стуктуры, аналог canvas-а).
                            Ваш негативный опыт с server-side components frameworks понятен, JSF отбивает желание работать с такими framework-ами раз и на всю жизнь. Но все таки, есть и хорошие server-side components frameworks, которые очень сильно облегчают жизнь, а не осложняют ее как JSF. Могу привести в пример Wicket и Vaadin.
                      0
                      Не совсем понятно что вы имеете в виду.
                    0
                    Как по мне, так одна из главных вкусностей это доведение до ума Java Config.
                      0
                      Полностью согласен.
                      Теперь дело за библиотеками-сателлитами (@Enable аннотации). Для MVC, транзакций, асинка, аспектов они уже есть.
                      Для Spring Security — еще нет. Это пока основной тормоз на пути прогресса, на мой взгляд.
                        +1
                        Так напишите, делов то! Они с радостью принимают патчи.
                          +1
                          Ну, в принципе, я и так автор таска на эту тему в их жире и автор поста в форуме Spring Security, где идет обсуждение этого вопроса.
                          Я начинал эту инициативу с полгода назад, когда правильным способом считались еще @FeatureSpecification. Сейчас способ импементации устаканился и можно садиться и делать, но… во-первых мне лень, во-вторых это большая тяжелая фича, охватывающая почти весь функционал подсистемы. Пускай сами делают.
                      0
                      jira.springsource.org/browse/SPR-8517
                      Самая главная фича Servlets 3.0 в этот релиз не вошла, к сожалению.

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

                      Самое читаемое