В моем предыдущем посте я показал, как можно с помощью Spring 3.0 развернуть приложение базы данных на CloudFoundry.com и какие изменения необходимы для источника данных CloudFoundry.com. В этой статье я собираюсь показать, как приложение Spring 3.1 можно настроить во время выполнения для использования либо локальной базы данных MySQL, либо базы данных MySQL CloudFoundry.com, что позволяет развертывать одно развертываемое приложение Spring либо локально, либо в CloudFoundry. ком.
Развертывание приложения Spring на CloudFoundry.com не требует использования Spring 3.1, однако Spring 3.1 значительно облегчает процесс благодаря новым функциям профиля. Итак, во-первых, мы должны обновить до Spring 3.1
Обновление до весны 3.1
Обновление приложения Spring STS для использования Spring 3.1 — простая процедура. В файле проекта pom.xml сначала нужно изменить номер версии Spring на 3.1.0.M1. Я говорю, что с приложением STS легко, так как все остальное (например, репозиторий Spring Milestone Maven) уже предварительно сконфигурировано в файле pom.xml .
Если вы не используете Maven, вы можете загрузить Spring 3.1 M1 со страницы загрузки сообщества .
Обновив версию в Maven, нам нужно изменить пространства имен для любых файлов контекста приложения. Это так же просто, как изменить расположение схемы на xxx-3.1.xsd вместо xxx-3.0.xsd
Обновление до Spring 3.1.M1, к сожалению, будет иметь некоторые побочные эффекты в STS. После обновления вы можете увидеть, что некоторые строки в файлах контекста приложения помечены ошибками, такими как:
Произошла ошибка при обработке XML ‘org / springframework / core / convert / support / ArrayToCollectionConverter’. Смотрите журнал ошибок для более подробной информации
Это потому, что STS (v2.6) в настоящее время не полностью поддерживает Spring 3.1 из-за некоторых изменений API в 3.1. Поддержка Spring 3.1 может быть отслежена в выпуске Jira SpringSource # 1655 .
Конфигурирование профилей определения бина
После настройки приложения на использование Spring 3.1 мы можем начать использовать функцию новых профилей для указания как источника облачных данных, так и локального источника данных.
В этом фрагменте XML мы видим, что внутри основного элемента <beans /> есть встроенные элементы <beans /> . Это новая функция Spring 3.1, которая позволяет легко указывать различные конфигурации в одном файле конфигурации. Здесь мы определили компонент с именем dataSource как источник данных JDBC и как источник данных CloudFoundry.com. профильАтрибут позволяет нам указать, в каком профиле должен быть создан экземпляр компонента. Таким образом, в профиле «по умолчанию», т. е. в локальном профиле, где наиболее вероятно выполнение разработки и тестирования, определен источник данных JDBC. «Облачный» профиль указывает источник данных для CloudFoundry.com. Профиль bean-компонента может быть настроен на несколько профилей, но в этом примере bean-компонент dataSource является либо локальным источником данных JDBC, либо источником данных CloudFoundry.com и никогда не может быть определен в обоих случаях.
Подробное описание профилей определения bean-компонентов Spring можно найти в блоге Chris Beams .
Выбор профиля во время выполнения
Последний этап изменения приложения для использования профилей определения бина, определенных выше, — это добавление класса, который реализует интерфейс org.springframework.context.ApplicationContextInitializer . Этот интерфейс позволяет настроить контейнер пружины до его инициализации. В нашем случае мы можем подключиться к этому и, в зависимости от среды, установить активный профиль как «по умолчанию», локальный источник данных JDBC или «облачный» источник данных CloudFoundry.com.
public class Initializer implements
ApplicationContextInitializer<ConfigurableWebApplicationContext> {
protected final Log logger = LogFactory.getLog(getClass());
public void initialize(ConfigurableWebApplicationContext ctx) {
ConfigurableEnvironment environment = ctx.getEnvironment();
ApplicationInstanceInfo instanceInfo = new CloudEnvironment()
.getInstanceInfo();
if (instanceInfo == null) {
// We are running locally.
logger.info("Setting default profile.");
environment.setActiveProfiles("default");
} else {
// We are running in the cloud.
logger.info("Setting cloud profile.");
environment.setActiveProfiles("cloud");
}
}
}
В этом классе мы пытаемся получить instanceInfo из CloudEnvironment класса. Если это возвращает нуль, приложение не работает на CloudFoundry.com, и локальный профиль определения компонента по умолчанию устанавливается в качестве активного профиля. Однако, если верный экземпляр возвращается, приложение работает на CloudFoundry.com, и в качестве активного профиля устанавливается профиль определения «облачного» компонента.
Это все, что нужно сделать, и теперь приложение может быть легко разработано и развернуто локально, насколько это возможно на CloudFoundry.com.
Пример кода, используемый в этом посте, можно найти на GitHib по адресу https://github.com/daveys/spring-todo.