Spring 3.1, Cloud Foundry и локальное развитие

Этот пост поможет вам создать веб-приложение Spring 3.1 с использованием MongoDB на Cloud Foundry. Помимо продвижения в Cloud Foundry, вы также сможете разрабатывать в своей локальной среде с экземпляром MongoDB.

цели

Целью публикации этого блога будет создание приложения локально, а затем публикация в локальном экземпляре Cloud Foundry. Мы будем использовать среду выполнения Cloud Foundry и новые Spring Profiles.

Настроить

1. Создайте учетную запись в Cloud Foundry ( https://www.cloudfoundry.com/micro ).
2. Следуйте инструкциям по настройке собственного Micro Cloud
   1. Я использую плеер VMWare
   2. Проверьте «vmc info», что консоль микро-облака соответствует
3. Загрузите MongoDB (как минимум версия 2.0)
4. Установите и ознакомьтесь с Maven 3 ( http://maven.apache.org )
5. Ознакомьтесь с Spring 3.1, Spring Data и Spring MongoDB
6. Клонируйте или загрузите исходный код ( https://github.com/mike-ensor/first-cloud-app )
7. Запустите приложение локально с помощью:

   1	mvn clean package cargo:run -DskipTests

8. Зайдите на http: // localhost: 8080 / home

профили

В Spring 3.1 появились новые профили среды, которые позволяют разработчику активировать группы компонентов на основе параметра среды. Я обнаружил несколько « ошибок », один из которых — недокументированный заказ бинов с использованием профилей.

Взгляните на data-services.xml . Обратите внимание, как MongoTemplate определяется перед. Это противоречит моей интуиции, потому что MongoTemplate берет ссылку на объект MongoFactory, который определен ниже определения MongoTemplate.

Вторая «ошибка» возникла, когда и где установить параметр для включения профилей Spring. В документации и блогах прямо не упоминается, что разработчик должен указать активный профиль. Из документации вытекает, что « default » было активным по умолчанию, но это не так. Чтобы профиль по умолчанию был активным, я добавил его в качестве системного свойства в настройках своего груза. (если это свойство системной среды, не стесняйтесь устанавливать его в любом месте или любым другим способом). Посмотрите на файл pom.xml в строке 40 для локального свойства Maven, а затем в строке 253 для устанавливаемой переменной среды.

Местное развитие против облачного развития

Одна из основных целей взаимодействия с Cloud Foundry — это то, что я хотел, чтобы локальная среда разработки ускорила и упростила разработку, а также уменьшила сложность с помощью отладки. Обратите внимание, что в
В data-services.xml есть «облачный» профиль и «default». Смысл профиля «по умолчанию» состоит в том, чтобы иметь bean-компоненты, созданные в локальной среде. Вы можете видеть, что существует два определения MongoFactory, одно из которых использует пространство имен Spring Data MongoDB XML, а другое — пространство имен CloudFoundry Runtime. Я не буду рассказывать, почему они работают так, как они работают, поэтому, если вам нужна информация, обратитесь к http://blog.springsource.org/2011/04/12/cloud-foundry-for-spring-developers/ и http://blog.springsource.org/2011/11/09/using-cloud-foundry-services-with-spring-applications-part-3-the-cloud-namespace/

Толчок к литейному облаку

Теперь, когда у вас есть локальный запущенный экземпляр веб-приложения, вы заметите, что артефакт называется « first-cloud-app.war », который вы можете найти в папке «/ target». Это проблема при отправке на экземпляр Cloud Foundry, поскольку имя не может содержать никаких буквенных символов. Инструмент vmc Cloud Foundry создан на основе проекта с открытым исходным кодом VCAP, который отвечает за службы PaaS с открытым исходным кодом. Другой сервис PaaS включает в себя App Fog, который позволяет вам в основном использовать те же команды, но заменить «vmc» на «af». Оба сервиса становятся жертвами проблемы именования.

Чтобы обойти проблему именования, я создал облако профилей Maven, которое создает артефакт WAR как mikeensor.war. Пожалуйста, измените это, чтобы соответствовать имени вашего приложения, так как у вас не будет пользователя / пароля для публикации (или DNS) для публикации на моем микроэкземпляре. Имя должно соответствовать шаблону URL http: // < applicationname >. .cloudfoundry.me.

Чтобы опубликовать в своем локальном облачном литейном микроэкземпляре, перейдите в корневую папку и введите следующее. (это предполагает, что ваш микроэкземпляр работает и нет «красных» ошибок.

(если вы уже нажали раньше, вам нужно будет набрать:

Примечание. Можно использовать плагин Maven для Cloud Foundry, однако я до сих пор не смог заставить его работать без изменения названия артефакта. Включение и подключение к услугам

Вы должны создать сервис (ы), чтобы ваше приложение могло связываться с источником данных. Приложение VCAP (vmc) управляет работой конфигурации при загрузке приложения в Cloud Foundry. Это делается через переменную среды, которая используется в элементе конфигурации пространства имен.

В моем примере я создал сервис MongoDB, набрав:

Я назвал мой «второй» (потому что я создал первый), и вы увидите, что в data-services.xml облачная XML-конфигурация ссылается на имя службы.

Обратите внимание, что если у вас есть несколько экземпляров MongoDB, вам нужно будет выполнить некоторые настройки Spring (@Qualifier), когда вы хотите использовать разные экземпляры. Это не охватывается этой публикацией в блоге.

Теперь вам нужно будет «привязать» сервис к вашему приложению. Это можно сделать, набрав:

Тестирование это

Вы должны быть в состоянии перейти на http: // . .cloudfoundry.me / home (пример: http://mikeensor.mikeensor.cloudfoundry.me/home)

Поздравляем! Вы должны были не только успешно развернуть приложение Cloud Foundry (микроэкземпляр), привязанное к экземпляру MongoDB, но и иметь возможность работать в вашей локальной среде! По мере того, как у меня будет время, я постараюсь добавить более подробные функции, такие как несколько типов хранилищ, и размещать другие «ошибки» по мере их нахождения.

Ссылка: Spring 3.1 + Cloud Foundry + Local Development от нашего партнера JCG Майка в блоге сайта Майка .