Каковы правила проксирования в CDI для bean-компонентов, когда они имеют перехватчик или декоратор?

Question

Я запустил 2 примера в weblogic (я использовал бин с зависимой областью действия):

1) у бина нет перехватчиков или декораторов: бин не был проксирован

2)у bean есть перехватчики: bean был проксирован

Я думаю, что в CDI есть два типа прокси:

1) клиентский прокси: этот прокси переопределяет все не приватные методы beanКласс, когда эти переопределенные методы вызываются, прокси ищет правильный экземпляр (или прокси второго типа) компонента, а затем перенаправляет вызов фактическому экземпляру компонента (на основе этой ссылки).для зависимой области действия этот прокси не создан

2) есть другой прокси для применения перехватчиков и декораторов, и он создается, когда у компонента есть декоратор или перехватчики

Является ли мое предположение о втором типе проксиправильный?В спецификации что-нибудь сказано об этом?

Answer 1

Вы действительно провели хорошее расследование, и вы правы по большей части.Вот подробности.

Прокси

Нормальные компоненты (@ApplicationScoped, RequestScoped, ...) действительно прокси, вы не получитефактического экземпляра и то, что вы получаете - клиентский прокси .С @Dependent, который не с нормальной областью действия, вы, как правило, хотите внедрять новый экземпляр каждый раз, поэтому нет необходимости в его прокси.

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

Перехватчики и декораторы

Переходя к перехватчикам - spec ничего не говорит об этом из того, что я знаю, и оставляет реализациям возможность свободно выбирать, что с ним делать.Следующие детали специфичны для сварки , хотя, насколько я помню, в OWB это похоже.В любом случае, вариантов достижения этого не так много.

Для каждого перехватчика / декоратора существует созданный «прокси», фактически подкласс, который позволяет осуществлять перехват / декорирование.Этот подкласс заменяет оригинальный компонент, и все вызовы проходят через него (например, он находится в базовом хранилище компонентов вместо исходного экземпляра).

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

Дополнительные инструменты для прокси / подклассов

Иногда очень редко, и, скорее всего, только при разработке библиотеки CDI вам может действительно понадобиться проверить, является ли внедренный компонент клиентским прокси или подклассом.Weld предлагает инструменты для этого, каждый компонент, имеющий прокси клиента, реализует интерфейс WeldClientProxy из Weld API.Этот интерфейс позволяет вам получить фактический экземпляр и некоторые метаданные.Аналогично, каждый перехваченный и оформленный компонент реализует WeldContruct в качестве интерфейса маркера.