Ошибки, которые вы получаете, обычно происходят из так называемой фазы проверки.Это делается во время развертывания и не означает, что фактические компоненты будут созданы.
На самом деле создание компонентов обычно выполняется лениво, особенно когда прокси находится в игре (например, любой компонент с нормальной областью действия).Это специфично для сварки, и другие реализации CDI не должны придерживаться этого, поскольку сама спецификация не требует / запрещает это.
На практике это означает, что когда вы @Inject Foo foo;
, все, что вы получаете, на самом деле является проксиобъект.«Оболочка» без состояния, которая знает, как получить так называемый контекстный экземпляр при необходимости .Контекстный экземпляр создается лениво, по требованию, когда вы впервые пытаетесь использовать этот компонент, как правило, когда вы впервые пытаетесь вызвать метод для него.
Благодаря статической природе CDI, во время развертывания всеЗависимости ваших bean-компонентов известны и могут быть проверены, поэтому вы можете проверить цепочку, которая была в вашем вопросе, и вы узнаете, все ли bean-компоненты доступны / неудовлетворены / неоднозначны.
Что касается динамического разрешения, например, Instance<Bar>
, это несколько другое.CDI может проверять только первоначальное объявление, которое у вас есть;в моем примере выше, это bean-компонент типа Foo
с квалификатором по умолчанию.Любые последующие вызовы методов .select()
выполняются во время выполнения, поэтому вам всегда нужно проверять, доступен ли экземпляр, который вы только что пытались выбрать, потому что вы можете легко выбрать либо тип, не являющийся компонентом, либо тип компонента, но с недопустимым квалификатором (с).Instance
API предлагает специальные методы для этого.