通过转到 Apache Shiro 并保留 Java EE 的 native API来进行安全性和 session 管理，有什么优势？
我发现所有安全角色和 session 都可以在Apache Shiro中完成，但是使用Java EE安全性也可以完成同样的事情，而无需任何外部依赖项jar。
因此，向我建议使用Apache Shiro的一些利弊。
我当然有失偏颇(我是Apache Shiro项目的提交者)，所以请按照您的意愿来考虑，但这是我的意见:
Java EE安全性不支持即开即用的独立于容器的 session 集群选项(Shiro支持)。 Shiro从一开始就被设计为可在POJO/依赖注入(inject)环境中工作。与传统的Java EE安全性环境相比，它使用界面驱动的设计并提供了更多的自定义 Hook (例如，如何显示当前使用Java EE安全性登录到您的站点的用户数？Shiro可以帮助您显示此信息)。 Shiro可以在任何应用程序环境中完全移植。如果您使用特定于Java EE供应商的安全性定制，则这些定制将不可移植(例如，此StackOverflow question表明切换到JBoss可能会解决用户的安全性问题-令人不安的IMO问题)。 与特定于服务器的自定义相同，许多Java EE安全性tutorials，articles和blog articles向您展示了基于用户界面的配置，该配置以跨平台的不同方式处理问题，如果您进行切换，可能会令人沮丧地重新学习。另外，Java EE配置通常需要XML。我更喜欢可以在任何地方使用的单一，非冗长的文本配置格式(shiro.ini很好，但是人们也可以使用groovy，yaml等配置shiro)。 Shiro旨在在任何应用程序环境中工作。 Java EE安全性设计得很好-仅适用于Java EE。至少当您学习Shiro时，您可以在任何基于JVM的应用程序(Spring，Guice，Java EE，命令行等)中利用这些知识，而不仅仅是Java EE应用程序。
HTH!
莱斯