что такое прокси spring

Прицельный обзор: Зачем Spring’у Proxy объекты

В Spring’е есть возможность указать родной для первого бина метод, при вызове которого будет создаваться и возвращаться новый экземпляр связанного бина. Помимо этого есть возможность переопределять методы с помощью MethodReplacer ‘a. Подробнее здесь.

Эти фичи требуют создания proxy объектов бинов, а реализуется все это безобразие с помощью всем известной библиотеки CGLib. После того, как beanFactory определил все метаданные для создания бина и не нашел его в кеше, то он пытается его создать следующим образом:

Оба эти класса объявляены внутри SubclassCreator ‘а. Метод enhancer.create() конструирует класс и создает экземпляр объекта этого класса.

Стоит заметить, что beanDefintion и beanFactory хранятся в полях SubclassCreator ‘а, и объявленные в нем классы имеют доступ к ним. Эти поля помечены модификатором final, что гарантирует доступ только на чтение к значениям этих полей.

Как можно заметить, переопределяемые методы представляют собой MethodOverride объект, который определяет его имя, имя объекта, которому он принадлежит и другую мета информацию о методе. Но сам по себе этот класс абстрактный, а наследуют его два класса:

Определяя тип переопределяемого метода, определяется индекс обработчика. Индекс обработчика задан в виде константы.

При вызове обработчика LookupOverrideMethodInterceptor вызывается создание бина с помощью beanFactory текущего бина по имени, которое задано в LookupOverride. Это имя попадает туда из соответствующей директивы конфигурации бинов:

При вызове ReplaceOverrideMethodInterceptor получается указанный в ReplaceOverride MethodReplacer и вызывается его основной метод с логикой, куда передается информация о вызванном методе, аргументах и самом объекте. Объект MethodReplacer также определяется в конфигурации директивой:

Как видно из данного обзора, подход оперирования именами бинов во всех частях конфигурации в некоторых ситуациях может вызывать достаточно большой overhead при работе с proxy объектами.

Posted by Code insiders 00:01 17.07.2012 Sighting review, Spring Framework

Источник

Русские Блоги

Три режима прокси прокси Java Spring

Три режима прокси Java

1. Агентская модель

Схема выглядит следующим образом:

1.1. Статический прокси (аналогично режиму декоратора)

При использовании статического прокси-сервера необходимо определить интерфейс или родительский класс. Прокси-объект и прокси-объект реализуют один и тот же интерфейс или наследуют один и тот же родительский класс.

Вот случай, который нужно объяснить:
имитируйте действие сохранения, определите интерфейс для действия сохранения: IUserDao.java, а затем целевой объект реализует метод UserDao.java этого интерфейса. В настоящее время, если вы используете метод статического прокси, вам необходимо установить прокси (UserDaoProxy.java) также реализует интерфейс IUserDao. При вызове вызовите целевой объект, вызвав метод прокси-объекта.
Следует отметить, что прокси-объект и целевой объект должны реализовывать один и тот же интерфейс, а затем вызывать метод целевого объекта, вызывая один и тот же метод.

Пример кода:
Интерфейс: IUserDao.java

Целевой объект: UserDao.java

Тестовый класс: App.java

Статическая сводка прокси:

Как устранить недостатки статического прокси? Ответ в том, что можно использовать динамический прокси

1.2. Динамический прокси

Динамический прокси, реализованный в режиме прокси JDK, целевой объектДолжен иметь интерфейс, Динамический прокси Jdk не может быть реализован без интерфейса

API динамического прокси:

Пакет, в котором расположен прокси-класс: java.lang.reflect.Proxy

В JDK API есть прокси, у которого есть метод для генерации динамического прокси newProxyInstance:

Возвращаемое значение: объект прокси-объекта

Параметры: загрузчик, тот же загрузчик классов, что и целевой объект, target.getClass (). GetClassLoader ();

Интерфейсы: Тип интерфейса, реализованного целевым объектом, и тип подтверждается с помощью универсального метода. target.getClass (). getInterfaces ();

H: обработка событий, когда выполняется метод целевого объекта, запускается метод обработчика событий, и метод текущего выполняемого целевого объекта будет передан в качестве параметра

Фильтры на основе методов динамического улучшения прокси:

Динамические агенты обладают следующими характеристиками:

подводить итоги:
Прокси-объект не должен реализовывать интерфейс, но целевой объект должен реализовывать интерфейс, иначе динамический прокси-сервер не может использоваться

1.3. Cglib прокси (реализован на основе наследования)

Вышеупомянутые режимы статического прокси и динамического прокси требуют, чтобы целевой объект был целевым объектом, который реализует интерфейс, но иногда целевой объект представляет собой просто один объект и не реализует какой-либо интерфейс. Способ, которым класс реализует прокси, называется этот метод: прокси Cglib

Прокси-сервер Cglib, также называемый прокси подкласса, создает в памяти объект подкласса для расширения функции целевого объекта.

Метод реализации прокси подкласса Cglib:

Источник

Что такое прокси в Spring?

Вам нужно будет отредактировать файл icon.svg, чтобы он соответствовал вышеуказанным критериям.

1 ответ

Прокси, сгенерированный для @Transactional поведение, служит другой цели, чем ограниченные по объему прокси.

Эти @Transactional прокси является тем, который обертывает определенный боб для добавления поведения управления сеансами. Все вызовы метода выполнят управление транзакциями прежде и после делегирования к фактическому бобу.

при иллюстрировании его это было бы похоже

@Scope прокси ведет себя по-другому. Состояния документации:

[. ] необходимо ввести объект прокси, который представляет тот же открытый интерфейс как ограниченный по объему объект , но это может также получить реальный целевой объект от соответствующего объема (такого как Запрос HTTP) и вызовы метода делегата на реальный объект.

то, Что действительно делает Spring, создает одноэлементное бобовое определение для типа фабрики, представляющей прокси. Соответствующий объект прокси, однако, запрашивает контекст для фактического боба для каждого вызова.

при иллюстрировании его это было бы похоже

, Так как MyBeanB опытный боб, контекст будет всегда возвращать новый экземпляр.

В целях этого ответа, предположите, что Вы получили MyBeanB непосредственно с [1 144]

, который является по существу, что Spring делает для удовлетворения @Autowired инжекционная цель.

В Вашем первом примере,

Вы объявляете опытный боб определение (через аннотации). @Scope имеет proxyMode элемент, который

Определяет, должен ли компонент быть настроен как ограниченный по объему прокси и если так, должен ли прокси быть основан на интерфейсе или основан на подклассе.

, Таким образом, Spring не создает ограниченный по объему прокси для получающегося боба. Вы получаете тот боб с [1 150]

, у Вас теперь есть ссылка на новое MyBeanB объект, созданный Spring. Это похоже на любой другой объект Java, вызовы метода перейдут непосредственно к экземпляру, на который ссылаются.

В Вашем втором примере,

Вы объявляете ограниченный по объему прокси, который реализован через cglib. При запросе боба этого типа от Spring с [1 154]

Spring знает, что MyBeanB ограниченный по объему прокси и поэтому возвращает объект прокси, который удовлетворяет API [1 121] (т.е. реализует все его открытые методы), который внутренне знает, как получить фактический боб типа MyBeanB для каждого вызова метода.

, Это возвратится true вывод подсказок тому, что Spring возвращает одноэлементный объект прокси (не опытный боб).

Вашим третьим примером является по существу то же как Ваша секунда.

Источник

Русские Блоги

Применение Spring прокси и аннотации в АОП

Сегодня я запишу АОП Spring и представлю его из следующих частей:

Модель агентства

Режим прокси часто встречался в исходном коде Android, например,Связывание процесса связиВ процессе использования AIDL текущие данные переноса потока будут определять необходимость перекрестной обработки. Если необходимо перекрестная обработка, данные инкапсулируются как объект Parcelable, а затем выполняется транзакционная функция, и агент, инкапсулированный в AIDL, завершил эти операции. Аналогично следующему примеру:

Нам нужно только вызвать прокси-класс EatAppleProxy, и нам не нужно самим писать процесс.

Java аннотации (Аннотация)

Аннотация предоставляет нам формальный способ добавления информации в код, чтобы мы могли удобно использовать данные позднее. Аннотация представлена ​​в JDK1.5 и более поздних версиях. Его можно использовать для создания документации, отслеживания зависимостей в коде и даже выполнения базовых проверок во время компиляции. Проще говоря, это добавить теги к некоторым кодам, чтобы облегчить последующую обработку кодов, которые добавляют единообразные теги.
Чтобы изучать аннотации, лучше всего научиться настраивать аннотации, чтобы вы могли лучше понять принципы аннотаций.
Мета аннотацииРоль отвечает за аннотирование других аннотаций. Java 5.0 определяет 4 стандартных типа метааннотаций, которые используются для предоставления инструкций для других типов аннотаций. Метааннотации, определенные Java5.0:

@Target

Объясняет диапазон объектов, измененных аннотацией, значения (ElementType):

@Retention

Определяет время хранения аннотации

@Documented

Используется для создания Java Doc.

@Inherited

Как настроить аннотации:

Используйте пользовательские аннотации

** Наиболее важным является получение содержимого аннотаций **: аннотации добавляются в java1.5, а также добавляется метод чтения аннотаций. Интерфейс AnnotatedElement добавляется в пакет java.lang.reflect. Исходный код JDK выглядит следующим образом:

Пожалуйста, посмотрите тестовый пример:

Динамический прокси Java

Динамические агенты Java делятся на динамические агенты JDK и динамические агенты CGLib. Как статический язык, Java не имеет стандартных динамических характеристик, таких как JavaScript, php, python и т. Д. Но Java постепенно добавляет некоторые функции для поддержки динамических функций, в том числе:Механизм отражения、Динамическая компиляция、Динамическое манипулирование байт-кодом、Динамическое преобразование типов Подождите.

JDK динамический прокси

Механизм отражения (отражения) на основе JDK В JDK предусмотрен интерфейс InvocationHandler. Исходный код объясняется следующим образом:

Метод агента CGLib

Мощная, высокопроизводительная, высококачественная библиотека генерации кода, которую можно использовать вРасширить класс Java и реализовать интерфейс Java во время выполнения, Нижний слой с помощью небольшого и быстрогоСреда обработки байт-кода ASMПреобразовать байт-код и создать новый класс. Видно, что CGLib изменяет выполнение Java со слоя байт-кода. Конкретные примеры использования следующие:

Очевидно, что MethodInterceptor здесь похож на InvocationHandler в динамическом прокси JDK.

Терминология и применение в АОП

На рисунке выше показана взаимосвязь между приведенными выше терминами.

В настоящее время Spring поддерживает только вызовы методов в качестве точек соединения (уведомление о выполнении методов в бинах Spring). Хотя можно добавить поддержку перехватчиков переменных-членов, не затрагивая основной API Spring AOP, Spring не реализует перехватчики переменных-членов. Если вам нужно получить доступ и обновить переменные-члены в качестве точки подключения для уведомлений, вы можете рассмотреть другие языки, такие как AspectJ.

Использование AOP в Spring может принять уникальную конфигурацию xml Spring или использовать AspectJ для реализации AOP.

Конфигурация Spring xml

AspectJ

Эта часть грамматики больше, рекомендуется использовать поисковый документ, конечно, помните лучше, портал,AspectJ использовать

Источник

Русские Блоги

Spring AOP анализ исходного кода создание прокси-объектов

1. Введение

В предыдущемстатьяВ статье я проанализировал, как Spring фильтрует подходящие уведомители для целевого bean-компонента. Теперь, когда советник выбран, следующим шагом будет вплетение рекомендаций, содержащихся в советнике (Advisor), в некоторые методы компонента через прокси. По сравнению с отбором подходящих уведомителей, процесс создания прокси-объектов намного проще: исходный код, анализируемый в этой статье, состоит всего из 100 строк, что относительно просто. В следующих главах я сначала познакомлю вас с некоторыми базовыми знаниями, а затем проанализирую исходный код. Тогда давайте сначала разберемся с базовыми знаниями.

2. Базовые знания

2.1 proxy-target-class

В конфигурации Spring AOP атрибут proxy-target-class может влиять на тип прокси-объектов, создаваемых Spring. В качестве примера возьмем конфигурацию XML, которую можно настроить следующим образом:

Как и выше, атрибут proxy-target-class по умолчанию равен false. Когда целевой bean-компонент реализует интерфейс, Spring создаст прокси-объект для целевого bean-компонента на основе динамического прокси-сервера JDK. Если интерфейс не реализован, Spring создаст прокси через CGLIB. Когда для атрибута proxy-target-class установлено значение true, Spring будет вынужден создавать прокси-объекты через CGLIB, даже если целевой bean-компонент реализует интерфейс.

На этом цель атрибута proxy-target-class подошла к концу.Давайте рассмотрим два различных способа создания динамического прокси.

2.2 Динамический прокси

2.2.1 Динамический прокси на основе JDK

Динамический прокси на основе JDK в основном создает прокси для целевого объекта через класс создания прокси Proxy, предоставляемый JDK.Давайте посмотрим на объявление метода создания прокси в Proxy. следующим образом:

Кратко расскажем о приведенном выше списке параметров:

Динамический прокси-сервер JDK имеет определенные требования к целевому классу, то есть целевой класс должен реализовывать интерфейс, а динамический прокси-сервер JDK может создавать прокси-объекты только для целевого класса, реализующего интерфейс. Что касается InvocationHandler, это тип интерфейса, который определяет метод вызова. Пользователь должен реализовать этот метод и инкапсулировать в нем логику прокси.

Давайте сначала поговорим о внедрении динамического прокси JDK. Позвольте мне продемонстрировать, как использовать динамический прокси JDK следующим образом:

Определение целевого класса:

Определение создателя агента:

Как и выше, логика прокси в методе вызова в основном используется для записи времени вызова и времени окончания целевого метода. Напишите тестовый код для простой проверки, как показано ниже:

Результаты теста следующие:

Что касается динамического прокси JDK, здесь много говорится. В следующем разделе я продемонстрирую динамический прокси CGLIB, так что давайте продолжим смотреть вниз.

2.2.2 Динамический прокси на основе CGLIB

Когда мы хотим сгенерировать прокси для класса, который не реализует интерфейс, мы не можем использовать динамический прокси JDK. Так что же делать, когда такой целевой объект генерирует прокси? Конечно, используется CGLIB. В CGLIB логика прокси инкапсулирована в классе реализации MethodInterceptor, а объект прокси создается с помощью метода create класса Enhancer. Позвольте мне продемонстрировать процесс создания прокси-объектов CGLIB следующим образом:

Источник изображения:Поиск изображений Baidu

Целевая категория, танк Тип 59:

Создатель прокси CGLIB

Метод восстановления танка-перехватчика:

Ладно, приступим к демонстрации, тестовый код такой:

Результаты теста следующие:

Хорошо, давайте наконец взглянем на 59 после магической реформы, Сверхзвуковой 59 Визуализации:

Источник изображения: неизвестно

В этом разделе в качестве примера используется танк Type 59. Как молодое поколение, мы должны поблагодарить тех научных и технических специалистов, которые внесли свой вклад в дело национальной обороны. Мы опасаемся, что без их вклада не было бы такой безопасной среды, как сегодня (хотя и не идеальной).

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

3. Анализ исходного кода

Перед созданием прокси-объекта для целевого bean-компонента необходимо сначала создать объект AopProxy, а затем вызвать метод getProxy этого объекта для создания фактического прокси-класса. Давайте посмотрим на определение интерфейса AopProxy, как показано ниже:

В Spring есть два класса, реализующие AopProxy, а именно:

В процессе создания прокси для целевого bean-компонента Spring решает, какой класс реализации AopProxy использовать для создания прокси-объекта для целевого bean-компонента, в зависимости от того, реализует ли bean-компонент интерфейс и некоторые другие конфигурации. Давайте посмотрим на процесс создания прокси следующим образом:

Как и выше, DefaultAopProxyFactory определяет, какой тип объекта класса реализации AopProxy генерировать на основе некоторых условий. После того, как объект класса реализации AopProxy сгенерирован, следующим шагом является создание прокси-объекта для целевого компонента. Взяв JdkDynamicAopProxy в качестве примера, давайте посмотрим на логику метода getProxy этого класса. следующим образом:

Как и выше, обратите внимание на последнюю строку действительного кода, вы обнаружите, что JdkDynamicAopProxy наконец вызывает метод Proxy.newProxyInstance для создания прокси-объекта. На этом этапе был проанализирован весь процесс создания прокси-объекта. Интересно, понимаете ли вы это. Хорошо, давайте остановимся на анализе исходного кода создания агента.

4. Резюме

В этой статье более подробно анализируется процесс создания прокси-объектов Spring AOP и вводятся соответствующие базовые знания перед анализом исходного кода. В целом технические моменты, затронутые в этой статье, не очень сложные, я думаю, что все могут понять. Ограничено личными возможностями, если в тексте есть ошибки, вы можете указать на них. Что ж, на этом статья заканчивается, спасибо за внимание.

Справка

Приложение: список статей об анализе исходного кода Spring

Эта статья опубликована под лицензией Creative Commons License 4.0, и источник должен быть указан в очевидном месте для перепечатки.
OF: coolblog.xyz
Эта статья одновременно опубликована в моем личном блоге:http://www.coolblog.xyz

Эта работа используетCreative Commons Attribution-Non-Commercial Use-No Derivation 4.0 International License AgreementСделайте разрешение.

Источник