Может ли внедрение зависимости CDI быть необязательным?

Question

В Spring DI объявление поля с автоматической связью как необязательного позволяет клиенту не вводить в него никакого значения. Возможно ли это с использованием CDI Java EE? Я попробовал Дополнительный, и это терпит неудачу. Я хочу знать, есть ли эквивалентный механизм, который я могу использовать.

Вот что я попробовал:

public class OmeletteMaker implements EggMaker{
        public static void main(String[] args){
        WeldContainer container = new Weld().initialize();
        OmeletteMaker omeletteMaker = container.instance().select(OmeletteMaker.class).get();
    }

    @Inject
    Optional<Vegetable> vegetable;
}

Я получаю сообщение об ошибке: Исключение в потоке "main" org.jboss .weld.exceptions.DeploymentException: WELD-001408 Неудовлетворенные зависимости для типа [Необязательно] с квалификаторами [@Default] в точке внедрения [[BackedAnnotatedField] @Inject cafeteria.OmeletteMaker.vegetable]

Answer 1

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

Во-первых, как правило, если вы @Inject a Fred, то Fred не может быть null, если только Fred находится в области действия @Dependent, и даже в этом случае метод производителя или пользовательский компонент должен быть явно записан для возврата null. Существуют крайние случаи, но во всех современных реализациях CDI это хорошее эмпирическое правило, о котором следует помнить.

Во-вторых, Optional не является особенным. С точки зрения CDI Optional - это просто еще один объект Java, так что смотрите мое первое утверждение выше. Если у вас есть что-то, что создает Optional (например, метод продюсера), то оно не может создать null Optional (если, опять же, производство не определено как область действия @Dependent - и если вы писали такой метод для создания Optional экземпляров и возврата null вы определенно запутаете своих пользователей). Если вы контролируете производство Optional экземпляров, то вы можете создавать их любым способом.

В-третьих, если вы хотите проверить, есть ли управляемый компонент или производитель какого-либо рода. для Fred вы можете, как указано в одном из комментариев к вашему вопросу, ввести Provider<Fred> или Instance<Fred>. Они «создаются» контейнером автоматически: вам не нужно писать что-то особенное, чтобы создавать их самостоятельно. Provider<Fred> является средством доступа к Fred экземплярам и не пытается получить экземпляр, пока не будет вызван его метод get(). Instance является Provider и Iterable всех известных Fred s и может дополнительно сказать вам, (а) является ли он «неудовлетворенным» - вообще нет производителей Fred - и (b ) это "разрешимо" - то есть существует ровно один производитель Fred.

В-четвертых, распространенная идиома в тех случаях, когда вы хотите посмотреть, есть ли что-то, чтобы ввести Instance, параметризованный с помощью введите нужный тип, а затем проверьте его метод isResolvable(). Если он возвращает true, то вы можете вызвать его метод get() и поверить, что его возвращаемое значение будет не-null (при условии, что оно не находится в области действия @Dependent).

Я надеюсь, что это полезно!