2014-02-03 5 views
1

У нас есть Maven несколько модулей проект со следующими модулями:Weld и тест-банка

  • PRJ-SRV
  • PRJ-клиент

СРВОМ проект содержит EJBs. В prj-srv/src/test у нас есть @Алтернативные реализации EJB, указанные в разделе альтернатив beans.xml. Это работает.

Проект prj-client имеет prj-srv как зависимость. Кроме того, он имеет зависимость от prj-srv типа test-jar, scope test, так что он может использовать альтернативные реализации EJB для тестов. Это тоже работает.

Теперь: в prj-client/src/main/java у нас есть локальные реализации интерфейсов EJB (чтобы мы могли кэшировать данные), аннотированные нашим определителем @Cacheable. То, что я хотел бы сделать, - это настроить тесты в prj-client/src/test/java, чтобы они использовали мои тестовые реализации из prj-srv (те, которые не кэшируемы, но кто заботится, так как это для тестирования).

Я попытался:

  • Создание класса с методами производителей (@Produces @Alternative @Cacheable) в Prj-клиент/SRC/тест/Java, но я не знаю, как настроить бобы .xml, чтобы установить это как альтернативный

  • Создание классов в prj-srv/src/test/java, которые расширяют тестовые EJB, аннотированные @Alternative @Cacheable и помещают их в src/test/resources/META- INF/beans.xml в разделе «Альтернативы», но сварка все еще вводит «настоящие» боты @Cacheable из src/main/java.

Есть ли проблемы с смешиванием @ Альтернативный с квалификаторами? Как я могу заставить свои тесты использовать альтернативные реализации квалифицированного класса?

ответ

1

Только что нашел: я забыл отметить конструкторы @Cacheable-реализаций с помощью @Inject. По-видимому, хотя это было отмечено как альтернатива в beans.xml, поскольку Weld не знал, как его инициализировать, вместо того, чтобы бросать ошибку, он просто молча решил игнорировать альтернативу ...

Смежные вопросы