NG
Я вообще был уверен, что если прокси на базе cglib, а не java proxy, то у меня нет "исходного" бина как такового, а всегда идёт работа с уже проинструментированным объектом.
Size: a a a
2021 January 15
NG
Но видимо ошибся
AG
Оказалось, что всё вообще не так просто. Все методы должны на самом деле возвращать не прокси-объект, а настоящий. Но я посмотрел код и оказалось, что есть специальный костыль, который подменяет настоящий объект на прокси-объект.
Он находится вот здесь:
Он находится вот здесь:
org.springframework.aop.framework.CglibAopProxy#processReturnType, более того, это поведение можно сменить с помощью интерфейса org.springframework.aop.RawTargetAccessNG
В общем, если кратко - спринг создаёт прокси над вашим классом, в этом прокси ваши методы обернуты в аспект(который видимо создаёт прокси над возвращаемым из метода объектом). Если метод вызывается на бине, то вся эта цепочка отрабатывает, если метод вызывается напрямую, то аспекты не отрабатывают
Конкретно эти методы аспектом не перехватываются. Но насколько я понимаю, это и не нужно - так как на какой-то из методов бина в принципе существует аспект/эдвайс, то объект проксируется целиком и перехватываются все методы. Просто некоторые сразу инвокаются, а некоторые проходят через эдвайсы
NG
Оказалось, что всё вообще не так просто. Все методы должны на самом деле возвращать не прокси-объект, а настоящий. Но я посмотрел код и оказалось, что есть специальный костыль, который подменяет настоящий объект на прокси-объект.
Он находится вот здесь:
Он находится вот здесь:
org.springframework.aop.framework.CglibAopProxy#processReturnType, более того, это поведение можно сменить с помощью интерфейса org.springframework.aop.RawTargetAccessО как... Любопытно, покопаюсь, спасибо!
DZ
Оказалось, что всё вообще не так просто. Все методы должны на самом деле возвращать не прокси-объект, а настоящий. Но я посмотрел код и оказалось, что есть специальный костыль, который подменяет настоящий объект на прокси-объект.
Он находится вот здесь:
Он находится вот здесь:
org.springframework.aop.framework.CglibAopProxy#processReturnType, более того, это поведение можно сменить с помощью интерфейса org.springframework.aop.RawTargetAccessвот где собака, спасибо!)
AG
Ага, ещё коммент прикольный
в этом методе
😂
в этом методе
// Massage return value if necessary😂
NG
Оказалось, что всё вообще не так просто. Все методы должны на самом деле возвращать не прокси-объект, а настоящий. Но я посмотрел код и оказалось, что есть специальный костыль, который подменяет настоящий объект на прокси-объект.
Он находится вот здесь:
Он находится вот здесь:
org.springframework.aop.framework.CglibAopProxy#processReturnType, более того, это поведение можно сменить с помощью интерфейса org.springframework.aop.RawTargetAccessА я правильно понимаю, что это поведение специфично для спринга, и при обычном использовании aspectj (без спринговых конфигураций) getThis будет возвращать оригинальный объект?
AG
Да, думаю, что да.
NG
Понятно, спасибо!
ВШ
Всем привет.
Подскажите может , кто сталкивался с таким .
С помощью maven-jaxb2-plugin генерирую классы по wsdl. И получаю ошибку
Two declarations cause a collision in the ObjectFactory class
Я так понял, что проблема в том что повторяются имена классов в wsdl и jabx на это ругается . А как эту коллизию можно разрешить ? wsdl стороннего сервиса их я менять получается не могу
Подскажите может , кто сталкивался с таким .
С помощью maven-jaxb2-plugin генерирую классы по wsdl. И получаю ошибку
Two declarations cause a collision in the ObjectFactory class
Я так понял, что проблема в том что повторяются имена классов в wsdl и jabx на это ругается . А как эту коллизию можно разрешить ? wsdl стороннего сервиса их я менять получается не могу
ВШ
Если в wsdl изменить имя конфликтного элемента то генерация происходит нормально .
C
Если вы про хибернейтовский ddl auto update - такое в прод пускать нельзя
кроме шуток, если у тебя простой круд (типа предлагаемого spring data rest) или приложение, где нет сложной бизнес логики с базой, то это нормально работает. Другое дело - повышается требования уровеня знания хибы
внешние ключи если что можно переименовывать и задавать самому, насколько я помню
а почему вдруг локально и на проде схема отлисаться будет? При условии, что девелопер делал ветку от той, которая задеплоена на инстансе
внешние ключи если что можно переименовывать и задавать самому, насколько я помню
а почему вдруг локально и на проде схема отлисаться будет? При условии, что девелопер делал ветку от той, которая задеплоена на инстансе
AE
кроме шуток, если у тебя простой круд (типа предлагаемого spring data rest) или приложение, где нет сложной бизнес логики с базой, то это нормально работает. Другое дело - повышается требования уровеня знания хибы
внешние ключи если что можно переименовывать и задавать самому, насколько я помню
а почему вдруг локально и на проде схема отлисаться будет? При условии, что девелопер делал ветку от той, которая задеплоена на инстансе
внешние ключи если что можно переименовывать и задавать самому, насколько я помню
а почему вдруг локально и на проде схема отлисаться будет? При условии, что девелопер делал ветку от той, которая задеплоена на инстансе
да банально данные не смигрирует
ВШ
Xautonameresolution как-то так называется
Выставлен уже этот аргумент в помнике
C
да банально данные не смигрирует
да, но не везде это надо
VS
Выставлен уже этот аргумент в помнике
Пользовал плагин от org.jvnet.jaxb2.maven2 0.14.0 нагенирированные классы в отдельный пакет аргумент решал проблему , из веб сервиса или файла генеришь ?
ВШ
Пользовал плагин от org.jvnet.jaxb2.maven2 0.14.0 нагенирированные классы в отдельный пакет аргумент решал проблему , из веб сервиса или файла генеришь ?
Из файлов