Разрешение внешних (сторонних) бобов в сварном шве

Question

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

Я еще не "установил" сварной шов, я просто читаю, и по этому вопросу я хочу убедиться, что правильно понял этот важный момент:

Достигнуто ли разрешение бинов, которые находятся в сторонних банках, путем объявления их как <alternatives> в вашем beans.xml?

Если нет, то как использовать bean-компоненты из сторонних библиотек, у которых нет beans.xml?

Поместить банку в путь к классам не получится, если в их META-INF нет beans.xml, что нельзя сделать для банок сторонних производителей. (см. пост Гэвина Кинга по теме )

Answer 1

почему так сложно думать?

Просто создайте методmermer для этих сторонних классов.

Предположим, у вас есть сторонняя библиотека, которая автоматически принимает файлы PDF и отправляет их по факсу, ивам нравится использовать что-то вроде

private @Inject PdfFaxService faxService;

в вашем коде, тогда вы можете просто предоставить это с помощью метода продюсера.PdfFaxService работает без сохранения состояния, поэтому мы можем с уверенностью предположить, что мы можем сделать его @ApplicationScoped:

public @Produces @ApplicationScoped PdfFaxService createFaxService() {
  return new PdfFaxService(initparameters);
}

где-нибудь.

hth.

Answer 2

Мое понимание альтернативы состоит в том, что это альтернатива какой-то другой реализации интерфейса, которую вы можете использовать в другой среде развертывания (например, в среде тестирования). альтернативный бин объявляется с пометкой @Alternative.

Чтобы использовать альтернативу в данном сценарии развертывания, выберите ее в элементе <alternatives> дескриптора развертывания CDI META-INF/beans.xml. Это включит @Alternative bean-компонентов, которые по умолчанию отключены.

Если включено, если контейнер обнаруживает неоднозначную зависимость для заданной точки внедрения, он будет искать альтернативы, которые могут быть внедрены, и, если таковая имеется, выбрать эту альтернативу.

Другими словами, альтернативы - это хороший способ заменить существующую реализацию на другую во время развертывания. Если заменить нечего, вам не нужны альтернативы, просто поместите флягу на путь класса. Хотя я не уверен, что это был именно ваш вопрос, у меня есть сомнения относительно концепции банок сторонних производителей.

Подробнее в 2.1.4. Альтернативы , 4.6. Альтернативы и 4.7. Исправление неудовлетворенных и неоднозначных зависимостей (но я думаю, это то, что вы читаете).

Обновление: Чтобы ответить на ваш дополнительный вопрос.

Если нет, то как использовать bean-компоненты из сторонних библиотек, у которых нет beans.xml

Этого не может быть, архив бобов должен иметь bean.xml (будь он пустым), как описано в разделе 15.6. Упаковка и размещение документации:

CDI не определяет никаких специальных архив развертывания. Вы можете упаковать бины в JAR, EJB-JAR или WAR - любые расположение развертывания в приложении CLASSPATH. Тем не менее, архив должен быть "архивом бобов". Это означает, что каждый архив, содержащий бобы включите файл с именем beans.xml в META-INF каталог пути к классам или WEB-INF каталог веб-корня (для Военные архивы). Файл может быть пустым. Бобы, развернутые в архивах, которые не иметь beans.xml файл не будет доступны для использования в приложении.

Затем, чтобы исправить неудовлетворенную и неоднозначную зависимость, обратитесь к ранее упомянутому разделу 4.7.

Обновление 2: Похоже, что с помощью BeforeBeanDiscovery.addAnnotatedType() можно добавить другие классы, которые следует учитывать при обнаружении компонента. (BeforeBeanDiscovery это событие)