Spring @Transactional v Spring Security @Secured不一致的行为

概述Spring文档建议将@Transactional注释放在具体的类/方法而不是接口上. Stack Overflow多次覆盖了这个原因,例如：Where should I put @Transactional annotation: at an interface definition or at an implementing class?Spring S

Spring文档建议将@Transactional注释放在具体的类/方法而不是接口上. Stack Overflow多次覆盖了这个原因,例如：

Where should I put @Transactional annotation: at an interface definition or at an implementing class?

Spring Security @Secured行为不同;大多数文档显示将注释放在界面上.事实上,无论您是使用JDK还是cglib代理,无论您是注释接口还是具体类,它似乎都有效.

这似乎是一个很好的解决方那么为什么不一致呢？对上述问题的一个答案表明性能影响……但是性能肯定对安全性同样重要吗？！

@Secured解决方案如何处理钻石继承问题(类实现2个接口都有@Secured相同的方法不同)？

最佳答案使用JDK代理和cglib时,最终TransactionInterceptor为@Transactional,MethodSecurityInterceptor为@Secured.

但是这两个MethodInterceptors使用不同的机制在给定的MethodInvocation上找到注释.

使用AnnotationUtils.findAnnotation(Method method,Class方法在SecuredAnnotationSecurityMetadataSource找到@Secured注释,而在AnnotationTransactionAttributeSource帮助SpringTransactionAnnotationParser时发现@Transactional.

看起来AnnotationUtils有更先进的机制来查找注释,搜索接口和声明类层次结构的方法.

您可以使用AnnotationUtils创建自己的TransactionAnnotationParser,这应该为@Transactional启用相同的功能.

AnnotationUtils返回第一个找到的注释,因此处理钻石继承的方式.

总结

以上是内存溢出为你收集整理的Spring @Transactional v Spring Security @Secured不一致的行为全部内容，希望文章能够帮你解决Spring @Transactional v Spring Security @Secured不一致的行为所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。