Spring框架，如何在不同项目中加载session
我有一个项目。 设置了会话
在第一个项目中，我在第一个项目中
req.getSession().setAttribute("x", name);
return "ses";
，我将其作为代码放在这里。在第二个项目中，我将其放在这里，
model.addAttribute("ses", req.getSession().getAttribute("x"));
return "oses";
但会话没有出现。
Spring框架如何让一个session出现在不同的项目中？
I have a project. In the first project I set the session
in my first project I put here as code
req.getSession().setAttribute("x", name);
return "ses";
In second project I put here
model.addAttribute("ses", req.getSession().getAttribute("x"));
return "oses";
but session is not appear.
How to make a session appear in different project with Spring framework?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你不能。 （好吧，也许您可以设置某种会话复制，但您不应该这样做。 查看相关问题）
您应该在应用程序之间使用其他形式的通信。该流程将更加复杂，并且包括通过（简单）Web 服务交换令牌，但这比依赖服务器容器要好，并且两个应用程序将在同一个容器中运行。
You can't. (Well, perhaps you can setup some sort of session-replication, but you shouldn't do it. See related question)
You should use other forms of communication between your applications. The flow will be more complicated and will include exchange of tokens through (simple) web services, but it is better than relying on the server container, and on the fact that both applications will be run in the same container.
描述你实际想要完成的任务会很有帮助；正如 Bozho 所说，您无法真正在应用程序之间共享会话对象。
但是，您可以使用 JMS（或任何其他应用程序内通信）将数据从一个应用程序发送到另一个应用程序。一旦您将数据放入接收应用程序中，您仍然需要能够决定如何处理该数据：如何将其与给定用户关联，如何将其放入该用户的会话中， 等等。
用户信息可以在消息中传递，但是两个系统之间必须有一些共同点，一些商定的密钥，可以用来确定信息属于谁。
一旦你掌握了这些，剩下的就是机制了；有很多有趣的游戏可以玩，但很容易搞砸:)
It'd be helpful to describe what you're actually trying to accomplish; as Bozho says you can't really share session objects between apps.
You could, however, use JMS (or any other intra-app comms) to send data from one app to another. You'll still need the capability to decide what to do with that data once you have it in the receiving app: how do I associate it with a given user, how do I get it into that user's session, and so on.
User information can be passed in the message, but there has to be some commonality between the two systems, some agreed-upon key, that can be used to figure out who the info belongs to.
Once you have that, the rest is mechanics; there are interesting games to be played, and it's easy to mess it up :)