подготовка
Настройтесь на какую-то конфигурацию. У вас уже установлена последняя версия NetBeans 7.1, и вы собираетесь загрузить ZIP- дистрибутив WebLogic 12c за секунду. После загрузки wls1211_dev.zip поместите его в выбранное место и разархивируйте. Отныне мы будем называть эту папку папкой% MW_HOME%. Откройте командную строку и настройте в ней переменные% JAVA_HOME%,% JAVA_VENDOR% и% MW_HOME%:
1
2
3
|
set JAVA_HOME=D:\jdk1.7.0_04 set MW_HOME=D:\temp\wls12zip set JAVA_VENDOR=Sun |
После того, как вы сделали это, последний шаг — запустить скрипт конфигурации установки configure.cmd в каталоге MW_HOME. Это единовременно.
Настройте свой домен WebLogic
Следующее, что нам нужно, это домен WebLogic. Откройте новую командную строку. Настройте среду в текущей оболочке, запустив сценарий% MW_HOME% \ wlserver \ server \ bin \ setWLSEnv.cmd. Выполните% MW_HOME% \ wlserver \ common \ bin \ config.cmd и следуйте указаниям мастера, чтобы создать базовый домен сервера WebLogic с именем test-domain в папке по вашему выбору (например, D: \ temp \ test-domain). Дайте имя пользователя и пароль по вашему выбору (например, system / system1) и нажимайте в мастере, пока у вас не появится кнопка «Готово». WebLogic нужен файл JAR клиента Derby для настройки и использования базы данных. Скопируйте derbyclient-10.8.2.2.jar из вашего репозитория m2 в папку test-domain \ lib. Теперь давайте запустим вновь созданный домен вручную, запустив startWebLogic.cmd в только что созданном доменном каталоге. Убедитесь, что все работает и работает, перейдя по адресу http: // localhost: 7001 / console и войдя в систему с учетными данными сверху. Перейдите к «Службы> Источники данных» и нажмите кнопку «Создать» над таблицей. Выберите «Общий источник данных» и введите имя по вашему выбору (например, GalleriaPool) и введите jdbc / galleriaDS в качестве JNDI-имени. Выберите Derby в качестве Типа базы данных и нажмите «Далее». Выберите драйвер Derby (тип 4), нажмите «Далее» и «Далее» и введите свойства подключения (База данных: GALLERIATEST, Хост: localhost. Пользователь и пароль: APP »и нажмите« Далее ». Если хотите, вы можете нажать нажмите кнопку «Проверить конфигурацию» сверху и убедитесь, что все настроено правильно.
Следующая самая сложная часть. Нам нужна сфера JDBC, подобная той, которую мы настроили для GlassFish. Первое отличие состоит в том, что мы на самом деле не создаем новую область, а добавляем механизм аутентификации к доступной. У WebLogic есть неприятное ограничение. Вы можете настроить столько областей безопасности, сколько захотите, но только одна из них может быть активной в данный момент времени. Это остановило меня на некоторое время, пока я не получил чаевые от Мишеля Шильдмейера (спасибо, кстати!). Перейдите к «Области безопасности» и выберите «myrealm» из таблицы. Перейдите на вкладку «Поставщики». Выберите «Новый» над таблицей провайдеров аутентификации. Введите «GalleriaAuthenticator» в качестве имени и выберите «SQLAuthenticator» из раскрывающегося списка в качестве типа. Нажмите ОК Выберите GalleriaAuthenticator, установите флажок управления: Достаточно и сохраните. После этого перейдите на вкладку «Специфично для провайдера». Введите следующее:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
|
Data Source Name: GalleriaPool Password Style Retained: unchecked Password Algorithm: SHA-512 Password Style: SALTEDHASHED SQL Get Users Password: SELECT PASSWORD FROM USERS WHERE USERID = ? SQL Set User Password: UPDATE USERS SET PASSWORD = ? WHERE USERID = ? SQL User Exists: SELECT USERID FROM USERS WHERE USERID = ? SQL List Users: SELECT USERID FROM USERS WHERE USERID LIKE ? SQL Create User: INSERT INTO USERS VALUES ( ? , ? ) SQL Remove User: DELETE FROM USERS WHERE USERID = ? SQL List Groups: SELECT GROUPID FROM GROUPS WHERE GROUPID LIKE ? SQL Group Exists: SELECT GROUPID FROM GROUPS WHERE GROUPID = ? SQL Create Group: INSERT INTO GROUPS VALUES ( ? ) SQL Remove Group: DELETE FROM GROUPS WHERE GROUPID = ? SQL Is Member: SELECT USERID FROM USERS_GROUPS WHERE GROUPID = ? AND USERID = ? SQL List Member Groups: SELECT GROUPID FROM USERS_GROUPS WHERE USERID = ? SQL List Group Members: SELECT USERID FROM USERS_GROUPS WHERE GROUPID = ? AND USERID LIKE ? SQL Remove Group Memberships: DELETE FROM USERS_GROUPS WHERE GROUPID = ? OR GROUPID = ? SQL Add Member To Group: INSERT INTO USERS_GROUPS VALUES( ?, ?) SQL Remove Member From Group: DELETE FROM USERS_GROUPS WHERE GROUPID = ? AND USERID = ? SQL Remove Group Member: DELETE FROM USERS_GROUPS WHERE GROUPID = ? Descriptions Supported: unchecked |
Сохраните ваши изменения. и вернитесь на вкладку «Поставщики». Нажмите на кнопку «Изменить порядок» и нажмите GalleriaAuthenticator в верхней части списка. Нажмите «ОК», когда закончите, и остановите ваш экземпляр WebLogic. Вы можете перезапустить его в любое время.
Настройте свои проекты
Java EE является переносимым. Правильно. И вы должны иметь возможность запускать то же самое развертывание без каких-либо изменений в WebLogic 12c. Это теория. На практике вам придется прикоснуться к развертыванию. Потому что у WebLogic есть некоторые проблемы с Hibernate. И это гораздо более капризно, когда речь идет о развертывании, чем GlassFish. Прежде всего вам необходимо создать папку «galleria-ear \ src \ main \ application \ META-INF». Поместите туда пустой файл weblogic-application.xml и вставьте в него следующий код:
1
2
3
4
5
6
|
<? xml version = '1.0' encoding = 'UTF-8' ?> < weblogic-application xmlns = "http://xmlns.oracle.com/weblogic/weblogic-application" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://xmlns.oracle.com/weblogic/weblogic-application http://xmlns.oracle.com/weblogic/weblogic-application/1.4/weblogic-application.xsd" > < prefer-application-packages > < package-name >antlr.*</ package-name > </ prefer-application-packages > </ weblogic-application > |
Это говорит WebLogic, что предпочтение отдается пакетным библиотекам приложений по сравнению с уже присутствующими на сервере. Вперед. Нам нужно добавить зависимости Hibernate на ухо. В GlassFish мы пропустили этот шаг, поскольку установили пакет Hibernate вместе с сервером. Вот так. Откройте galleria-ear pom.xml и добавьте следующее в раздел зависимостей:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
|
< dependency > < groupId >org.hibernate</ groupId > < artifactId >hibernate-entitymanager</ artifactId > < version >4.0.1.Final</ version > </ dependency > < dependency > < groupId >org.hibernate</ groupId > < artifactId >hibernate-core</ artifactId > < version >4.0.1.Final</ version > </ dependency > < dependency > < groupId >org.hibernate</ groupId > < artifactId >hibernate-validator</ artifactId > < version >4.2.0.Final</ version > </ dependency > < dependency > < groupId >org.jboss.logging</ groupId > < artifactId >jboss-logging</ artifactId > < version >3.1.0.CR2</ version > </ dependency > |
Вам также нужно взглянуть на плагин maven-ear и добавить следующее в <configuration>:
1
|
< defaultLibBundleDir >lib</ defaultLibBundleDir > |
И, если вы уже там, удалите jarModule для кодека commons. Это не больно, но оно упаковано в папку ear / lib, так что вы можете пропустить это.
Затем перейдите к проекту galleria-jsf и откройте web.xml. <Login-config> является неполной и должна выглядеть так:
1
2
3
4
5
6
7
|
< login-config > < auth-method >FORM</ auth-method > < form-login-config > < form-login-page >/Login.xhtml</ form-login-page > < form-error-page >/Login.xhtml</ form-error-page > </ form-login-config > </ login-config > |
1
2
3
4
|
< security-role > < description >All registered Users belong to this Group</ description > < role-name >RegisteredUsers</ role-name > </ security-role > |
Вам также необходимо определить возможные роли, иначе сотрудники службы безопасности WebLogic начнут жаловаться.
Добавьте пустой файл weblogic.xml в папку galleria-jsf \ src \ main \ webapp \ WEB-INF и добавьте в нее следующие строки:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
|
<? xml version = "1.0" encoding = "UTF-8" ?> xsi:schemaLocation = "http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd" > < security-role-assignment > < role-name >RegisteredUsers</ role-name > < principal-name >RegisteredUsers</ principal-name > </ security-role-assignment > < session-descriptor > < timeout-secs >3600</ timeout-secs > < invalidation-interval-secs >60</ invalidation-interval-secs > < cookie-name >GalleriaCookie</ cookie-name > < cookie-max-age-secs >-1</ cookie-max-age-secs > < url-rewriting-enabled >false</ url-rewriting-enabled > </ session-descriptor > </ weblogic-web-app > |
Здесь мы сопоставляем роль web.xml и роль WebLogic. Вы могли бы пропустить это, но мне так нравится, чтобы вы не запутались. Элемент session-descriptor заботится об имени файла cookie JSESSION. Если вы не измените его, у вас возникнут проблемы с вошедшими пользователями в консоль администратора.
Двигайтесь по проекту galleria-ejb. Создайте пустой файл weblogic-ejb-jar.xml в папке «galleria-ejb \ src \ main \ resources \ META-INF». Вставьте в него следующий код:
1
2
3
4
5
6
7
8
|
<? xml version = "1.0" encoding = "UTF-8" ?> < weblogic-ejb-jar xmlns = "http://xmlns.oracle.com/weblogic/weblogic-ejb-jar" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://xmlns.oracle.com/weblogic/weblogic-ejb-jar http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.0/weblogic-ejb-jar.xsd" > < security-role-assignment > < role-name >RegisteredUsers</ role-name > < principal-name >RegisteredUsers</ principal-name > </ security-role-assignment > </ weblogic-ejb-jar > |
Сравнимый с web.xml / weblogic.xml, он также сообщает WebLogic, как сопоставить роли безопасности ejb-jar.xml с ролями WebLogic. Хорошо, откройте файл persistence.xml и добавьте следующие строки:
1
2
3
|
< property name = "hibernate.dialect" value = "org.hibernate.dialect.DerbyDialect" /> < property name = "hibernate.transaction.jta.platform" value = "org.hibernate.service.jta.platform.internal.WeblogicJtaPlatform" /> |
Первый явно выбирает диалект дерби для Hibernate. Второй рассказывает Hibernate, где и как искать транзакции. Все сделано. Теперь вы сможете снова собрать проект и развернуть его. Используйте консоль администратора или NetBeans для ее развертывания. Спасибо, что нашли время, чтобы следовать этому длинному сообщению. Я надеюсь, что это было полезно!
Хотите знать, что нужно для запуска модульных и интеграционных тестов ? Читай дальше!
Время двигаться дальше с примером Vineet Java EE 6 Galleria. После небольшого вступления , базового руководства по началу работы с GlassFish и развертыванием WebLogic 12c, пришло время погрузиться в тестирование. Я пропустил эту часть в предыдущих постах по двум причинам. Первое, очевидно, было то, что я хотел написать отдельный пост об этом. Вторым было то, что нужно было поработать, чтобы запустить и запустить последнюю версию GlassFish 3.1.2. Vineet и его команда проделали отличную работу, выпустив Arquillian GlassFish Remote Container CR3 несколько дней назад, который теперь также охватывает GlassFish 3.1.2. Пора начать с тестирования Galleria Example.
Что вы собираетесь проверить
Galleria была разработана для обеспечения всестороннего охвата тестов с помощью модульных и интеграционных тестов, написанных в JUnit 4. Модульные и интеграционные тесты для EJB и модель предметной области основаны на API контейнера EJB 3.1. Интеграционные тесты для уровня представления опираются на проект Arquillian и его расширение Drone (для выполнения тестов Selenium).
Пожалуйста, не забудьте обновить последние источники из проекта Galleria, потому что Vineet обновил контейнер Arquillian GlassFish до CR3 и Selenium для поддержки новейшего браузера FireFox.
Юнит-тестирование уровня домена
Тесты для доменного уровня делятся на пять отдельных категорий. Первые три (тесты Bean Verification, тесты взаимной регистрации, тесты для конструктора, методы equals и hashcode) покрывают основные потребности практически любого приложения на основе JPA. Если вы прогуляетесь по источникам galleria-ejb \ src \ test, вы увидите их в пакете info.galleria.domain. Каждый объект домена покрывается классом набора, который включает все три вида модульных тестов.
Давайте начнем с рассмотрения тестов Bean Verification. Поведение, связанное с методами получения и установки в свойствах JavaBeans, довольно легко проверить. Все, что нужно сделать, это сначала вызвать установщик, затем получатель и проверить, равен ли экземпляр, возвращаемый получателем, экземпляру, переданному установщику. Проект использует
Класс BeanVerifier (в корне src / tests / java модуля galleria-ejb) для этого. Тест AlbumBeanVerifier просто является параметризованным тестом, который проверяет каждое отдельное свойство. Единственным исключением в этом случае является свойство coverPhoto, которое имеет особое поведение помимо простого шаблона JavaBean.
Далее в списке идут тесты для методов конструктора, equals и hashcode. Конструкторы для сущностей домена проверяются путем простого создания новых экземпляров классов, в то же время утверждая валидность свойств, которые будут установлены конструктором. Методы equals и hashcode проверяются с помощью класса EqualsVerifier из проекта EqualsVerifier .
Последняя категория более базовых тестов — это тесты взаимной регистрации (PDF). Вы просто хотите проверить, действительно ли изменения в отношениях между сущностями приводят к изменениям как родительских, так и дочерних свойств. Смотрите всестороннюю вики-страницу для более подробной информации о реализации. Все они выполняются на этапе модульного тестирования и охватываются классами ** / * Suite.java.
В дополнение к базовым тестам вы также найдете одноразовые тесты, написанные для конкретных случаев, когда базовые тестовые модели недостаточны или непригодны. В таких случаях одноразовые тесты проверяют такое поведение с помощью рукописных утверждений. Вы найдете их в классах ** / * Tests.java в том же пакете.
Тесты на уровне домена заканчиваются тестами репозитория JPA. Каждый из классов * RepositoryTest.java тестирует поведение CRUD обработанных доменных объектов. Общий AbstractRepositoryTest обрабатывает тестовые данные и сбрасывает базу данных после каждого запуска теста. Само создание базы данных обрабатывается плагином maven-dbdeploy. Взглянув на файл pom.xml, вы увидите, что он связан с двумя фазами жизненного цикла Maven (process-test-resources и pre-интеграция-test), что обеспечивает его повторный вызов дважды. Первый раз перед юнит-тестами и второй перед интеграционным тестированием (сравните ниже).
Все эти юнит-тесты выполняются безошибочно. Если вы выполните mvn-тест для проекта galleria-ejb, вы увидите, что в общей сложности прошло 138 тестов. Это четыре теста ** / * Suite, четыре ** / * RepositoryTests и два дополнительных теста. Если вы кратко посмотрите на вывод консоли, то увидите, что все это происходит в среде Java SE. Контейнерные тесты до сих пор не проводились.
Интеграционное тестирование уровня домена
Так что это действительно охватывало только основы, которые каждый должен делать и, вероятно, знает. Проведение интеграционного тестирования — другая история. Это делается с помощью тестов ** / * IntegrationSuite. Имя намеренно не использует соглашения об именах по умолчанию, чтобы предотвратить их запуск на этапе модульного тестирования Maven. Чтобы подключиться к этапам тестирования интеграции Maven, в примере Galleria используется плагин Maven Failsafe . Вы можете найти комплект интеграционных тестов в пакете info.galleria.service.ejb. AbstractIntegrationTest заботится об обработке тестовых данных (сравнимых с тем, что AbstractRepositoryTest) делал для юнит-тестов. Набор содержит * ServiceIntegrationTest для каждого объекта домена. Вы можете пройти отдельные тесты в каждом * IntegrationTest и почувствовать, что здесь происходит. ServicesIntegrationSuite заботится о запуске и остановке EJBContainer с помощью AbstractIntegrationTest.startup () ;. Этот метод сравнительно не впечатляющий и простой:
1
2
3
4
5
6
7
|
logger.info( "Starting the embedded container." ); Map<String, Object> props = new HashMap<String, Object>(); props.put( "org.glassfish.ejb.embedded.glassfish.installation.root" , "./glassfish-integrationtest-install/glassfish" ); container = EJBContainer.createEJBContainer(props); context = container.getContext(); datasource = (DataSource) context.lookup( "jdbc/galleriaDS" ); |
Наиболее важным моментом здесь является то, что встраиваемый EJBContainer настраивается через существующий домен GlassFish, который можно найти непосредственно в папке galleria-ejb \ glassfish -grationtest-install. Если вы посмотрите на glassfish \ domains \ domain1 \ config \ domain.xml, то увидите, что все настройки для вас уже выполнены. Но откуда происходит развертывание? Это легко ответить. По умолчанию встраиваемый EJBContainer ищет в вашем classpath jar-файлы или папки ejb-jar и развертывает их. Если вы хотите увидеть более подробный вывод из EJBContainer, вы должны предоставить файл customlogging.properties в src / test / resources и добавить в него несколько простых строк:
1
2
3
4
5
|
handlers=java.util.logging.ConsoleHandler java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter java.util.logging.ConsoleHandler.level=FINEST #add some more packages if you need them info.galleria.service.ejb.level=FINE |
добавьте следующее в раздел конфигурации maven-failsafe-plugin вашего pom.xml:
1
2
3
4
|
< systemPropertyVariables > < java.util.logging.config.file >${basedir}/src/test/resources/customlogging. properties</ java.util.logging.config.file > </ systemPropertyVariables > |
Интеграционные тесты должны успешно завершиться, и maven должен напечатать что-то похожее на следующее:
1
|
Tests run: 49, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 61.726 sec |
Обратите внимание, что интеграционные тесты занимают значительно больше времени, чем обычные юнит-тесты. Это совсем не удивительно, и вы должны выполнять их только тогда, когда это необходимо, чтобы не замедлять процесс разработки.
Интеграционное тестирование уровня презентации
Доменный слой покрыт тестами. Чего не хватает, так это уровня представления. Вы можете найти тесты презентационного уровня в проекте galleria-jsf. Начните с изучения pom.xml. Вы найдете пару новых зависимостей здесь. А именно Аркиллиан, Селен и Дрон.
Сначала снова немного настроек. Прокрутите вниз до раздела профиля, и вы увидите профиль интеграционного теста, который использует плагин maven-glassfish-plugin и управляет контейнером, который настроен с помощью нескольких свойств. Добавьте определение в раздел свойств в верхней части pom:
1
2
3
4
5
6
7
8
9
|
< galleria.glassfish.testDomain.user >admin</ galleria.glassfish. testDomain.user> < galleria.glassfish.testDomain.passwordFile >D:/glassfish-3.1.2-b22/glassfish3/glassfish/domains/ test-domain/config/local-password</ galleria.glassfish.testDomain.passwordFile > < galleria.glassfish.testDomain.glassfishDirectory >D:/glassfish-3.1.2-b22/glassfish3/glassfish/</ galleria.glassfish.testDomain.glassfishDirectory > < galleria.glassfish.testDomain.domainName >test-domain</ galleria.glassfish.testDomain.domainName > < galleria.glassfish.testDomain.adminPort >10048</ galleria.glassfish.testDomain.adminPort > < galleria.glassfish.testDomain.httpPort >10080</ galleria.glassfish.testDomain.httpPort > < galleria.glassfish.testDomain.httpsPort >10081</ galleria.glassfish.testDomain.httpsPort > |
Вы можете скопировать это из профиля разработки проекта galleria-ejb, как описано в части 2 . Вы также должны уже иметь домен на месте. Далее вы увидите, что плагин maven-surefire-plugin следует тем же правилам, что и проект galleria-ejb. Но, глядя на тестовые классы, вы видите, что здесь нет ни одного юнит-теста. Таким образом, вы можете перейти непосредственно к maven-failsafe-plugin, который обрабатывает интеграционные тесты. Существует один единственный AllPagesIntegrationTest, который охватывает полное тестирование. Пойдем туда.
Это Arquillian Testcase, который выполняется как клиент против удаленного экземпляра. Помимо определения развертывания (@Deployment) вы также снова видите несколько методов setUp и tearDown, которые выполняют некоторую инициализацию и уничтожение. Одна вещь должна быть обработана отдельно. Вы также видите там метод writeCoverageData (), который, очевидно, подключается к какому-либо сокету и считывает данные из него. Это хук JaCoCo (Java Code Coverage Library), который может создать набор данных покрытия тестов. Для этого вам нужно скачать пакет и распаковать его в любое место по вашему выбору. Затем перейдите в свой тестовый домен GlassFish \ config \ domain.xml и откройте его. Найдите server-config — java-config и добавьте туда следующее:
1
|
< jvm-options >-javaagent:D:\path\to\jacoco-0.5.6.201201232323\lib\jacocoagent.jar=output=tcpserver</ jvm-options > |
Это позволяет агенту покрытия для GlassFish. Все настройки сделаны сейчас. Возвращаясь к NetBeans, выберите профиль интеграционного теста (в NetBeans вы можете сделать это, выбрав запись из выпадающего списка рядом с небольшим молотком в области значков или используя -Pintegration-test в качестве переключателя командной строки maven. Консоль Выходные данные сообщают вам, что домен GlassFish запущен и запущен info.galleria.view.AllPagesIntegrationTest. Имейте в виду, что во время этого запуска появляется экземпляр FireFox, а расширение Arquillian Drone управляет вашими тестами Selenium.
Видеть браузер с дистанционным управлением таким образом выглядит и выглядит странно, если вы не видели этого раньше. Если все работает, вы должны увидеть это в выводе консоли:
1
|
Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 138.014 sec |
Если вы используете в своем браузере другую локаль, чем en, возможно, вы полностью провалили тесты. Так что есть дополнительная необходимость настроить Drone для его поддержки . Drone позволяет вам указать профиль Firefox через arquillian.xml. Вы можете создать профиль Firefox, который настроен на отправку заголовков на языке принятия с использованием en / en-US в качестве значения.
Чтобы создать новый профиль, запустите диспетчер профилей Firefox следующей командой (вам может потребоваться закрыть все запущенные экземпляры): firefox -profilemanager (в Windows вам нужно выполнить команду «d: \ complete \ path \ to \ firefox.exe» ”-Profilemanager) в командной оболочке. Запомните место на диске, где создан этот профиль — оно понадобится вам позже. Чтобы настроить созданный профиль, в Firefox перейдите в Параметры (меню) -> Содержание (вкладка) -> Языки (набор полей) -> Выберите, чтобы добавить английский язык (и переместить его вверх, как предпочтительный). Теперь перейдите по galleria-jsf \ src \ test \ resources \ arquillian.xml, затем вы можете добавить свойство:
1
2
3
4
|
< extension qualifier = "webdriver" > < property name = "implementationClass" >org.openqa.selenium.firefox.FirefoxDriver</ property > < property name = "firefoxProfile" >location of the Firefox profile for English</ property > </ extension > |
Все сделано сейчас. Вы должны быть в состоянии запустить весь процесс очистки и сборки без каких-либо ошибок теста. Большой «зеленый бар» 🙂
Ссылка: Пример Java EE 6 — Запуск Galleria в WebLogic 12 — Часть 3. Пример Java EE 6 — Тестирование Galleria — Часть 4 от нашего партнера JCG Маркуса Эйзела в блоге