Как-то я засиделся на работе добавляя новую функциональность в один "небольшой" и довольно старенький сервис написанный на Spring.

Редактируя очередной XML файл Spring конфигурации я подумал: а чего это в 21 веке мы всё еще не перевели наш проект на Java-based конфигурации и наши разработчики постоянно правят XML?

С этими мыслями и была закрыта крышка ноутбука в этот день...

Первый подход: "Да сейчас руками быстро все сконвертирую, делов-то!"

Вначале я попробовал решение в лоб: по-быстрому сконвертировать XML конфигурации в Java классы в текущей задаче.

Переведя с десяток бинов руками выходило, что на перевод одной конфигурации у меня уходит примерно час, а это значит что на перевод всего проекта уйдёт порядка недели.

И еще есть большая вероятность человеческого фактора внесения ошибок: не туда скопировал, перепутал порядок полей и т. д, а это еще трата N времени на ровном месте.

Плюс проектов с XML у меня на самом деле еще и несколько и надо бы и их перевести. Собственно в этот момент и появилась идея автоматизировать конвертацию.

Второй подход: "Автоматическая конвертация. От идеи к реализации"

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

Тогда появилась идея написать свою утилиту. Но чтобы не погрязнуть в Spring (а за много лет там было написано столько всего, что ого-го) было сделано решено ввести на старте несколько ограничений:

• Конвертор не должен явно обращаться к классам проекта - это важное ограничение введено намерено чтобы не уйти во все тяжкие рефлексии и случайно не написать второй Spring. Исключения тут составляют Java конфигурации импортированные в XML.

• Чтение конфигураций с bean definitions должно быть аналогично чтению самого Spring - теми же reader-ами - org.springframework.beans.factory.xml.XmlBeanDefinitionReader.

• Генерация конфигурации должна быть на базе собственной модели - чтобы был строгий контроль поддерживаемых описаний бинов.

• Конвертируются типовые бины, вся "экзотика" допереводится руками.

В итоге схема работы утили получилась следующая:

Через тернии к звездам

Часть из этого была известна заранее, часть нашлась по ходу дела - набралось много интересного про XML конфигурации Spring. Я просто обязан всем этим поделиться :-)

Spring допускает в XML конфигурация много вольностей и "трюков", самые интересные найденные много описаны ниже.

Spring позволяет делать многократные вложения бинов и это вполне - норм

 <bean id="BeanWithConstructorWithCreateSubBeanWithSubBeanAndMap"
          class="pro.akvel.spring.converter.testbean.BeanWithConstructorWithCreateSubBeanWithSubBeanAndMap">
  <constructor-arg>
    <bean class="pro.akvel.spring.converter.testbean.SubBeanWithSubBean">
      <constructor-arg>
        <bean class="pro.akvel.spring.converter.testbean.SubSubBean">
          <constructor-arg>
            <bean class="pro.akvel.spring.converter.testbean.SubSubBeanWithMap">
              <constructor-arg type="java.lang.String">
                <null/>
              </constructor-arg>
            </bean>
          </constructor-arg>
        </bean>
      </constructor-arg>
    </bean>
  </constructor-arg>
</bean>

Пришлось реализовать рекурсивный обход описаний, как при проверке валидации бинов, так и в момент генераторе кода.

Поддержка импортов Java конфигураций

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:task="http://www.springframework.org/schema/task"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans.xsd
           http://www.springframework.org/schema/task
           http://www.springframework.org/schema/task/spring-task-3.0.xsd
           http://www.springframework.org/schema/context
           http://www.springframework.org/schema/context/spring-context.xsd">
    <context:annotation-config/>

    <import resource="classpath:pro/akvel/spring/converter/xml/configs/spring-bean-configuration-import.xml"/>
</beans>

Да, оказывается все новое у нас в проектах уже пишется на Java-конфигурациях и чтобы сконвертировать старое нужно уметь зачитать и новые конфигурации.

Тут на помощь пришел спринговый ConfigurationClassPostProcessor, который как раз умеет дочитать описание бинов объявленных в классах.

В конверторе есть ключ для включения строгого режима, который проверяет, что все импорты присутствуют в classpath

А еще есть коллекции бинов

<bean id="BeanWithPropertyList"
          class="pro.akvel.spring.converter.testbean.BeanWithPropertyList">
  <property name="prop1">
    <list>
      <ref bean="bean1"/>
      <ref bean="bean2"/>
     </list>
  </property>
  <property name="prop2">
    <set>
      <ref bean="bean1"/>
    </set>
  </property>
</bean>

Довольно просто получилось добавить генерацию ArrayList и HashMap по коду.

Но остался не поддерживаемым случай, когда поле назначения типа массив, это спринг уже угадывает сам по коду проекта получая тип поля куда сеттятся Mergeable объекты.

А еще в XML можно переменные окружения использовать

<bean id="BeanWithPlaceholder"
          class="pro.akvel.spring.converter.testbean.BeanWithPlaceholder">
  <constructor-arg value="test${pl1}passed"/>
  <constructor-arg value="${pl2}"/>
  <property name="property1" value="test${pl1}passed"/>
  <property name="property2" value="${pl2}"/>
  <property name="property3" value="${pl1} and ${pl2}"/>
</bean>

Этот случай получилось поддержать. В момент генерации класса конфигурации переменные окружения добавляются полями с аннотациейorg.springframework.beans.factory.annotation.Value

Часть бинов создается через фабрики

Тут все не так однозначно, если с фабричным методом все понятно (т.к. класс бина описывается в XML), то поддержку AbstractFactoryBeanна полях сделать не удалось, поэтому бины с фабриками пропускаются и остаются жить в XML.

А еще в XML можно кастомные неймспейсы делать и расширять DSL

Ну а чего б нет, и их довольно много даже у самого Spring (Например: http://www.springframework.org/schema/c, http://www.springframework.org/schema/p). XML конфигурации с такими xmlns не смогут корректно прочитаться, поэтому первую конвертацию следует делать с флагом -s что отловить и по возможности убрать кастомные xmlns.

А еще спринг умеет угадывать тип поля из XML

Привести String к int вообще мелочь, на самом деле даже можно досоздавать объекты (например поле Resource со значение file: - досоздаст объект класса FileSystemResource)

public class MyBean {
    private Resource resource;
}

Спокойно прожевывает конфигурацию, и создавая new FileSystemResource("my_file.txt")

<bean id="my-bean" class="MyBean">
  <property name="resource" value="my_file.txt" />
</bean>

Этот случай уходит в ручную доконвертацию. Т.е. утилита выставит String значение в конструктор или seter, дальше нужно руками привести поле к нужному классу.

А еще можно писать код прямо в XML через Expression Language #{}

Большие ребята могут себе позволить поддерживать свой EL. Я к сожалению не могу :) Бины с EL будут пропущены и останутся в XML.

А еще спринг умеет сам поискать поля которые разработчик забыл прописать в XML

А вот это вообще киллер фича, которую лучше показать на примере:

Допустим есть класс:

public class MyBean {
    private final MyBean1 service1;
    private final MyBean2 service2;

    MyBean(MyBean1 service1, MyBean2 service2) {
        this.service1 = service1;
        this.service2 = service2;
    }
    ...
}

И конфиг к нему

 <bean id="my-bean" class="MyBean">
   <constructor-arg ref="service1"/>
 </bean>

Так вот, при отсутствии одного из параметра конструктора, Spring поищет бины с таким типом и если в контексте ровно один бин такого типа, то он его сам доавтовайрит и корректно создаст бин. Утилита конечно такое делать не умеет, т.к. не ходит в исходники проекта.

Это нужно будет поправить сами. В ходе конвертации наших проектов был найден ряд таких бинов и добавлены необходимые поля в ручную.

А еще в проекте XML файлы могут лежать по разным модулям и ссылаться на бины друг друга через ref без явных импортов или зависимости модулей

При сборке все XML конфигурации оказываются в ресурсах и Spring их найдет и корректно поднимет контекст. При это явный импорт одной XML конфигурации в другую не требуется.

Тут пришлось отказаться от перевода модулей одного репозитория по отдельности, а сделать сканирование всего проекта и создания общего описания бинов. И уже потом по этому общему описанию переводить конфигурации.

Я уж молчу что Spring вообще плевать на приватность полей и методов

Имхо это большой минут, т.к. теряется понимание зон видимости. При переводе на Java конфигурацию стало видно какие классы/методы/модули на сам деле не приватные в проекте и утекли. К счастью у меня таких классов было немного.

Итоги

В результате получилась универсальная утилита, которая позволила перевести часть наших активно развивающихся сервисов в Java конфигурацию, что значительно повысило удовольствие работы с проектами.

Какие плюсы конвертации можно выделить:

• Повышена комфортность собственной работы, а так уменьшение по времени на правки конфигов: начинают в полную силу работать плюшки IDE: рефакторинг, автодополнение, генерация кода и т.д.

• Повышена прозрачность конфигурации: нет неявной автоподстовновки, нет обращений к приватным классам, полям, классам

• Все зависимости между модулями теперь стали явными - теперь если один модуль требует бин другом модуля, эту зависимость требуется явного объявить в pom.xml/build.gradle модуля, что позволяет отлавливать некорректную связанность при написании кода или на ревью.

Код и релизы находятся тут - spring-xml-to-java-converter (лицензия MIT)

Что уже сейчас поддерживается:

• Мультимодульные проекты.

• Неявные зависимости конфигураций.

• Автоматическое удаление сконвертированных бинов из XML конфигураций.

• Бины без "id".

• Параметризованные бины constructor-arg/property.

• Бины с переменными окружения.

• Вложенные бины.

• Бины с list/set.

• Бины с фабричным методом.

• Аттрибуты lazy, depend-on, init-method, destroy-method, scope, primary.

Что НЕ поддерживается:

• Именованные параметры конструкторов полей.

• Абстрактные бины и бины с родителями.

• Бины с фабриками, когда не указан явно класс создаваемого фабрикой объекта.

• Бины с EL выражениями, либо со ссылкой на classpath.

• Бины со ссылкой на бин, который отсутствует в созданном BeanDefinitionRegistry.

Подробная инструкция по работы с утилитой находится в readme репозитория.

P.S. Стоит или не стоит переводить свой проект?

Мое лично мнение, что любой Spring-проект рано или поздно стоит перевести на Java-based конфигурацию, но хочется отметить несколько важных моментов.

Когда стоит задуматься, а готов ли проект к переводу:

• Если проект плохо покрыт тестами или вы не готовы потратить время на регрессионное тестирование.

• Когда проект в архиве - не стоит переводить проект "на будущее" без релиза. Это может сыграть злую шутку, например когда нужно будет срочно выкатить hotfix.

• Когда в XML конфигурации много самописных xmlns расширений - это все придется сконвертировать руками.

• Когда проект является частью родительского проекта на XML - если в проект работает много команд следует заранее договорится о переводе своего модуля, чтобы все были готовы.

Когда точно стоит переводить:

• Проект активно развивается и изменяется - разработка станет сильно приятнее и эффективнее после конвертации.

Спасибо что дочитали, надеюсь было полезно (⊙‿⊙).