Spring @Transactional v Spring Security @ Безопасное противоречивое поведение

Question

В документации Spring рекомендуется размещать аннотацию @Transactional для конкретного класса / метода, а не для интерфейса. Причина этого неоднократно упоминалась в переполнении стека, например:

Где разместить аннотацию @Transactional: в определении интерфейса или в классе реализации?

Spring Security @Secured поведение отличается; большая часть документации показывает размещение аннотации на интерфейсе. На самом деле, похоже, это работает, независимо от того, аннотируете ли вы интерфейс или конкретный класс и не зависимо от того, используете ли вы прокси JDK или CGLib.

Это кажется превосходным решением. Так почему несоответствие? Один ответ на вышеуказанный вопрос предполагает влияние на производительность ... но, безусловно, производительность так же важна для безопасности?!

А как решение @Secured решает проблему наследования алмазов (класс реализует 2 интерфейса, в обоих случаях один и тот же метод @Secured)?

Answer 1

При использовании обоих прокси-серверов JDK и CGLib вы получаете TransactionInterceptor для @ Transactional и MethodSecurityInterceptor для @Secured.

Но эти два MethodInterceptors используют разные механизмы для поиска аннотации по заданному MethodInvocation .

@ Защищенная аннотация найдена SecuredAnnotationSecurityMetadataSource с использованием AnnotationUtils.findAnnotation (Метод метода, класс annotationType) * метод 1021 *, в то время как @Transactional обнаруживается AnnotationTransactionAttributeSource с помощью SpringTransactionAnnotationParser .

10* Похоже, что AnnotationUtils имеют гораздо более продвинутые механизмы поиска аннотаций, разделяя как интерфейсы, так и метод объявления иерархии классов.

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

AnnotationUtils возвращает первую найденную аннотацию, таким образом, как обрабатывается наследование алмазов.