Решил тут в свободное время поуглублять знания, возникли следующие вопросы, а как это все работает то?
В настоящее время мои теоретические знания по работе аннотаций ограничены прочтением статьи здесь.
То есть, аннотации — просто по большому счету пометки кода.
Соответственно интересует, а как работают такие аннотации, как @transational в спринге? Чтобы при входе в метод транзакция стартовала, а на выходе был commit или rollback? Это вроде уже модификация выполняемого кода идет, кто ее выполняет, на каком этапе? Тем способом, который описан в статье такие фокусы не сделать, насколько я понимаю.
Может кто хорошие ссылки на то, как это работает подсказать? Ну, или просто на пальцах объяснить
Здравствуйте, elmal, Вы писали:
E>Решил тут в свободное время поуглублять знания, возникли следующие вопросы, а как это все работает то? E>В настоящее время мои теоретические знания по работе аннотаций ограничены прочтением статьи здесь. E>То есть, аннотации — просто по большому счету пометки кода. E>Соответственно интересует, а как работают такие аннотации, как @transational в спринге? Чтобы при входе в метод транзакция стартовала, а на выходе был commit или rollback? Это вроде уже модификация выполняемого кода идет, кто ее выполняет, на каком этапе? Тем способом, который описан в статье такие фокусы не сделать, насколько я понимаю. E>Может кто хорошие ссылки на то, как это работает подсказать? Ну, или просто на пальцах объяснить
Аннотации можно брать в рантайме (здесь);
Спринг реализует aop через рантайм прокси (Aspect Oriented Programming with Spring, Spring AOP APIs), т.е. он отдает тебе из контекста не объект класса, определенного в конфиге, а прокси над ним, который делаеи всю 'грязную работу';
Поэтому существуют разные способы их анализа.
Один из них Compiler API. Который позволяет на этапе компиляции отлавливать нужные аннотации. И производить нужные действия.
Второй способ это рефлексия. Например утрированое описание работы с аннотацией для транзакций.
Спринг знает класс. Вычитывает его методы. Смотрит через Reflection API их аннотации. Если есть транзакционнные, то запоминает в каких методах с каким полиси. Когда создается экзаемпляр класса. Он оборачивается в Proxy. Прокся перехватывает все вызовы методов у экземпляра. И сравнивает вызываемые методы со своим списоком который составлен по анализу класса. Ну и в соответствии с этим производит нужные действия.
Очень рекомендую почитать про концепцию AOP. В общем, без привязки к конкретным реализациям, чтобы понять зачем это надо. Аннотации это один из способов реализовать концепцию AOP в Java.
Здравствуйте, Blazkowicz, Вы писали:
B>Попробуй на пальцах
Очепятался. Конечно же "попробую".
Re[2]: как работают аннотации?
От:
Аноним
Дата:
13.02.08 16:42
Оценка:
B>Очень рекомендую почитать про концепцию AOP. В общем, без привязки к конкретным реализациям, чтобы понять зачем это надо. Аннотации это один из способов реализовать концепцию AOP в Java.
Может посоветуе-те что-то конкретное почитать по AOP?
Здравствуйте, Аноним, Вы писали:
B>>Очень рекомендую почитать про концепцию AOP. В общем, без привязки к конкретным реализациям, чтобы понять зачем это надо. Аннотации это один из способов реализовать концепцию AOP в Java. А>Может посоветуе-те что-то конкретное почитать по AOP?
Здравствуйте, Blazkowicz, Вы писали:
B>Очень рекомендую почитать про концепцию AOP. В общем, без привязки к конкретным реализациям, чтобы понять зачем это надо. Аннотации это один из способов реализовать концепцию AOP в Java.
Приятно читать подобные посты.
Лет много назад, когда я работал в группе, что делала AspectJ (ещё в PARC), я им говорил — надо добавить в язык произвольные метки к методам и типам, чтоб AOP ориентировался на них, а не на имена этих методов и классов. На что мне сказали, мол, я нифига не понимаю в AOP, и это никому не нужно. Вскоре меня попёрли из тима — окончательно их добило то, что я не умею "планировать" свою работу (ну, 2.5 часа на поправить тут, 1 день на реализовать здесь и т.д.).
Нынче эти "метки" в яве реализованы через аннотации, и являются основой работы AOP.
Мораль сей басни такова — если я был такой умный 7 лет назад, что разбирался в реальных нуждах AOP лучше автора — то насколько же я умнее сейчас. И если я потратил эти годы на разработку новой концепции программирования — насколько эта концепция более продвинута, чем AOP! Впрочем, у этой басни есть и другая мораль — насколько мало людей в состоянии осознать то, о чём я говорю
Здравствуйте, mkizub, Вы писали:
M>Нынче эти "метки" в яве реализованы через аннотации, и являются основой работы AOP. M>Мораль сей басни такова — если я был такой умный 7 лет назад...
Череп не жмет?
Такие метaданные в то время уже были реализованы как минимум в C#.
Здравствуйте, Blazkowicz, Вы писали:
M>>Нынче эти "метки" в яве реализованы через аннотации, и являются основой работы AOP. M>>Мораль сей басни такова — если я был такой умный 7 лет назад... B>Череп не жмет? B>Такие метaданные в то время уже были реализованы как минимум в C#.
Не жмёт. Просто удивительно, как некоторые люди не видят очевидного. Вот ты, например, не увидел о чём я пишу.
А писал я о том, как привязывать пойнткаты к методам и типам, а не о аннотациях. Аналогичная привязка, до появления аннотаций в яве, в AspectJ обеспечивалась тегами в комментариях.
Здравствуйте, mkizub, Вы писали:
M>Не жмёт. Просто удивительно, как некоторые люди не видят очевидного. Вот ты, например, не увидел о чём я пишу. M>А писал я о том, как привязывать пойнткаты к методам и типам, а не о аннотациях. Аналогичная привязка, до появления аннотаций в яве, в AspectJ обеспечивалась тегами в комментариях.
Ну, так пиши о том о чем ты хочешь написать, а не о том что ты думал что хотел написать, чтобы потом сказать что тебя никто не понял.
Здравствуйте, mkizub, Вы писали:
M>Лет много назад, когда я работал в группе, что делала AspectJ (ещё в PARC), я им говорил — надо добавить в язык произвольные метки к методам и типам, чтоб AOP ориентировался на них, а не на имена этих методов и классов.
Да что-то похоже, что правильно сказали. Как я читаю, что у вас написано выше. Вместо того, чтобы задать сразу множество методов, в которые будет внедрен код, вы предлагали делать так. Указать каждый метод, в который нужно внедрить код с помощью специальной метки.
Насколько я разобрался с AOP, этот подход в корне не правильный. Где же выделение аспектов, которые перпендикулярны основной задаче? Получается, что я могу элементарно забыть установить метку методу и его логгирование производится не будет. Или не будет решен аспект безопасности. Или, разработчик специально забудет эту метку поставить?
Хорошо разобраться со Spring AOP у меня руки не дошли, но насколько я понял, речь идет о другом. Вместо придумывания своего языка, предлагается задавать пойнткаты с помощью аннотаций методов которые будут внедрены. А никак не наоборот (по крайне мере, AspectJ аннотации именно так сейчас и используются).
Здравствуйте, LeonidV, Вы писали:
LV>Насколько я разобрался с AOP, этот подход в корне не правильный. Где же выделение аспектов, которые перпендикулярны основной задаче? Получается, что я могу элементарно забыть установить метку методу и его логгирование производится не будет. Или не будет решен аспект безопасности. Или, разработчик специально забудет эту метку поставить?
"Перпендикулярны" это хорошо сказано. Я так понимаю, ты об ортогональности? А о самодокумендированности кода ты не?
AOP в его изначальной идее — это грязный хак. Как средство расширения языка он может использоваться, но для этого надо иметь расширяемый язык — определяемые программистом операции (реализация которых и будет отображена через аспекты, а самодокументированность будет уже в том, что эти операторы имеют другое "имя"), расширяемые декларации типов/методов/переменных (каковое расширение частично можно сделать через аннотации, и они же являются средством самодокументации кода) и пр.
А изначальный способ AOP — изменение кода программы без указания в коде мест, где это изменение будет сделано, без возможности найти все влияющие на код пойнткаты из декларации и контекста кода — это грязный хак, ни на что, кроме отладки не годный.
Вот тебе простой пример. synchronized методы — это аналог around адвайса. Что, если разработчик "забудет" поставить модификатор synchronized — кто ему виноват? А что, если нечто будет расставлять синхронизацию по произвольным методам в программе — про дедлоки которые немедленно вылезут ты догадываешься?
Где практически можно использовать AOP кроме логирования? Вот с аннотациями (а перед тем с тегами в комментариях — минус которых в том, что они не сохраняются в байткоде) его начали реально использовать. А до того, куда его только не пихали — а он всё не впихивался.
