Обновление до весны 3.2

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

Обновление до Spring 3.2 — это очень простой вопрос обновления номера версии Maven и перестройки, что-то вроде этого:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>3.2.1.RELEASE</version>
</dependency>

… для каждой зависимости Spring, а затем перекомпилировать
и это как раз об этом … за исключением того, на этот раз есть несколько
ошибок .

… что кажется странным. Исправление заключается в добавлении spring-web в зависимости вашего файла pom.xml:

<!-- Add this as Spring 3.2.1-RELEASE update -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-web</artifactId>
    <version>${org.springframework-version}</version>
</dependency>

… вероятно где-то рядом:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webmvc</artifactId>
    <version>${org.springframework-version}</version>
</dependency>

Вы можете спросить, почему это происходит, и у меня есть теория. Это всего лишь предположение, но кажется логичным, что в предыдущих версиях Spring была временная зависимость между spring-webmvc и spring-web, которой больше не существует, и поэтому вам необходимо специально добавить свою собственную зависимость spring-web.

Теперь это просто общая ошибка; однако в двух проектах Github, посвященных отладке капитана:
tomcat-ssl и
социальная STS / eclipse обнаружили проблему в XML-файле контекста Spring. Линия была:

 <annotation-driven/>

Ошибка была:

Error occured processing '/social/src/main/webapp/WEB-INF/spring/appServlet/servlet-context.xml'

… и ассоциированное исключение было:

java.lang.NoClassDefFoundError: org/springframework/web/accept/ContentNegotiationManagerFactoryBean
 at org.springframework.web.servlet.config.AnnotationDrivenBeanDefinitionParser.getContentNegotiationManager(AnnotationDrivenBeanDefinitionParser.java:293)
 at org.springframework.web.servlet.config.AnnotationDrivenBeanDefinitionParser.parse(AnnotationDrivenBeanDefinitionParser.java:151)
 at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
 at org.springframework.ide.eclipse.beans.core.internal.model.namespaces.DelegatingNamespaceHandlerResolver$ElementTrackingNamespaceHandler.parse(DelegatingNamespaceHandlerResolver.java:177)
 at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1419)
 at org.springframework.ide.eclipse.beans.core.internal.model.BeansConfig$ErrorSuppressingBeanDefinitionParserDelegate.parseCustomEleme
etc…

Как и проблема @RequestMapping, описанная выше, эта проблема заключалась в неправильных переходных зависимостях. В случае проекта tomcat-ssl проблема была вызвана вытягиванием web-безопасности Spring в Spring-Web версии 3.1.0-RELEASE, а не 3.2.1-RELEASE. Аналогичным образом, в социальном проекте проблема была вызвана использованием Spring-social-twitter в Spring-web версии 3.0.7, а не в 3.2.1-RELEASE

. Исправление, опять же, заключается в добавлении Spring-web в качестве зависимости в вашем проекте.

<!-- Add this as Spring 3.2.1-RELEASE update -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-web</artifactId>
    <version>${org.springframework-version}</version>
</dependency>

Проблемы с EhCache

После того, как все веб-проекты снова заработали, следующая проблема возникла в примере кода ehcache. Этот проект также прекратил компиляцию, и это потому, что класс org.springframework.cache.ehcache.EhCacheCacheManager не найден. Причину этого можно найти в документации Spring. Ребята из Spring перевели поддержку EhCache в виде пакета org.springframework.cache.ehcache из модуля spring-context в поддержку spring-context-support. Причина этого кажется разумной, потому что EhCache не является передовым Spring-пакетом, это вспомогательный пакет и, следовательно, входит в spring-context-support для уменьшения раздувания модулей наряду с jcache, mail, кварцевым планированием и commonj, в то время как на фронте пользовательского интерфейса он содержит бесплатный маркер, отчеты о яшме и поддержку скорости.

Чтобы решить эту проблему, добавьте в файл pom.xml следующее:

<dependency>
       <groupId>org.springframework</groupId>
       <artifactId>spring-context-support</artifactId>
       <version>${spring.version}</version>
</dependency> 

Неправильная версия Java

В нескольких проектах я получил следующую ошибку при запуске mvn clean install в среде STS / eclipse:

org.apache.maven.surefire.util.SurefireReflectionException: java.lang.reflect.InvocationTargetException; nested exception is java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.UnsupportedClassVersionError: caching/EhCachePersonDAOTest : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)

Причина этого в том, что в процессе сборки использовалась Java 6, а не Java 7. Помните, что это старые, существующие проекты, изначально созданные с использованием Java 6, а затем обновленные по мере необходимости. Решение этой проблемы — вручную изменить версию среды выполнения Java на Java 7 в свойствах проекта, как показано на рисунке ниже:

CGLib больше не требуется

Это не очевидная проблема, но ребята из Spring убрали необходимость специально включать CGLib в ваш проект. CGLib требуется, если вы используете аннотацию @Configuration. Версия 2.2 обычно добавляется в ваш pom.xml, когда вы создаете новый проект с использованием параметра
Spring Template Project на панели инструментов STS, как показано ниже:

<!-- CGLIB, only required and used for @Configuration usage: could be removed in future release of Spring -->
<dependency>
    <groupId>cglib</groupId>
    <artifactId>cglib-nodep</artifactId>
    <version>2.2</version>
</dependency>

Как говорят ребята из Spring в своей документации:

в предыдущих версиях пользователи прокси-серверов AOP на основе подклассов Spring (например, через proxy-target-class = «true») и поддержка класса @Configuration были обязаны объявить явную зависимость от CGLIB 2.2 , Начиная с Spring Framework 3.2, мы теперь переупаковываем и подключаем недавно выпущенный CGLIB 3.0. Это означает большее удобство для пользователей, а также правильную функциональность для пользователей Java 7, которые создают прокси подклассов типов, которые содержат инструкции invokedynamicbytecode. Внутренняя переупаковка CGLIB гарантирует отсутствие конфликтов пути к классам с другими сторонними средами, которые могут зависеть от других версий CGLIB.

Обновление схем проекта

Это необязательно, но вы также можете изменить заголовки Spring XML с 3.1 на 3.2, чтобы указанная ссылка на XML-схему заканчивалась на -3.2.xsd. Например:

http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd

становится

http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.2.xsd

Самый простой способ сделать это — использовать глобальную замену eclipse для замены -3.1.xsd на -3.2.xsd, но сначала сделайте быструю проверку, прежде чем делать это …

Это изменение действительно необходимо, только если вы хотите использовать любые новые функции, которые определены в файлах XML-схемы 3.2. Я внес изменения только для того, чтобы выяснить, были ли проблемы с обратной совместимостью, и не было, все было хорошо.

И это все. Если вам нужно узнать об обновлении до Spring 3.1, взгляните на
этот старый блог, и если вы все еще используете Spring 2.x и хотите обновить его до 3, то посмотрите
этот еще более старый блог .