在 HttpSessionListener 中如何获取 HttpServletRequest？
如何从 SessionListener 访问请求标头？
我需要在创建当前会话时为其设置超时。 超时需要根据 HttpServletRequest 中的标头而变化。 我已经有一个 SessionListener （实现 HttpSessionListener）来记录新会话的创建和销毁，它似乎是设置超时的最合乎逻辑的地方。
我尝试了以下方法，但它总是将 ctx 设置为 null。
FacesContext ctx = FacesContext.getCurrentInstance();
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
HttpSessionListener无法访问请求，因为它是在未发出请求时调用的，以通知会话销毁。因此，
Filter或Servlet是检查请求和指定会话超时的更好位置。The
HttpSessionListenerdoes not have access to the request because it is invoked when no request has been made—to notify of session destruction.So, a
FilterorServletwould be better places to examine the request and specify the session timeout.JSF 上下文是针对每个请求的并且是线程本地的。 因此，此方法调用可能会在 JSF 控制器调用之外返回 null（例如 FacesServlet.service) - 因此，其他线程和任何不通过 Faces Servlet 映射的请求。
从技术上讲，可以使用 JSF 机制设置此超时 - 您可以使用 阶段侦听器 在 渲染响应，但您仍然需要 转换为 servlet API 以设置超时。 阶段侦听器的优点是它们可以在 faces-config 中全局注册（请参阅规范）或具体观点。 在 JAR 中使用 META-INF/faces-config.xml 定义的全局阶段侦听器可以放入多个 WAR 中，从而使您可以轻松地重用该功能。
（您还可以覆盖会话的配置方式到 JSF，但工作量过多。）
对于一次性的，erickson 的建议 过滤器非常简单。
JSF contexts are per-request and thread-local. So, this method call will probably return null outside the JSF controller invocations (e.g. FacesServlet.service) - so, other threads and any requests that don't pass through the Faces servlet mapping.
It is technically possible to set this time-out using a JSF mechanism - you could use a phase listener to check for a session after RENDER RESPONSE, though you would still have to cast to the servlet API to set the time-out. The advantage of phase listeners is that they can be registered either globally in faces-config (see spec) or for specific views. A global phase listener defined in a JAR with a META-INF/faces-config.xml can be dropped into multiple WARs, allowing you to easily reuse the functionality.
(You could also override how the session is provisioned to JSF, but the amount of work is excessive.)
For a one-off, erickson's suggestion of a Filter is really straightforward.
您不能（请参阅API）。 该请求允许您访问会话，但反之则不行。
您甚至可能对同一会话有并发请求，因此这是不可行的。
You can't ( see the API ). The request allows you to access the session, but not the other way around.
You might even have concurrent requests for the same session, so this is not feasible.