java 中的常规会话处理

General session handling in java

我使用多种语言工作,例如 PHP、C、JAVA 等。 我试图完全理解会话在 java 中是如何实现的。

问题:在 php 中,我可以创建会话并在任何 class 甚至实用程序 class 中使用该会话。在 Java 为什么会话只能在 servlet classes 中正常处理?为什么不在任何基本 POJO classes 中不实际传递会话或上下文对象? (我知道其他 classes 可以,使用复杂的技术,但为什么不像 servlet 或其他语言那样容易)。

我知道正确的做法是在 Servlet 中使用会话来检索 object/values 并将 object/values 传递给其他实用程序 classes 并获得结果。

请告诉我是否真的有一种在基本 POJO 中获取会话的简单方法 classes。

从 Servlet class 将会话传递给任何助手 class(创建 HTTPSession 作为助手 class 属性)。

现在在您的 POJO 中 class 从您之前从 servlet 设置的助手 class 获取会话。

Question : In php I can create a session and use the session in any class even utility classes. In Java why session is meant to be handled normally only in servlet classes? why not in any basic POJO classes without actually passing session or context object ? (I know other classes can, using complex techniques, but why not easily as servlet or as in other languages )

每种语言都有自己的设计和结构。没有通用的会话处理协议,它应该在所有服务器端语言中以相同的方式处理。在 java 如果在控制器中处理会话即 servlet 设置和获取属性符合您的目的,为什么有人想要在 POJO 中获取会话对象。您可以将 POJO 保存在 servlet 的会话中。

此外,如果有超出规范要求的例外情况,您始终可以编写自定义代码。

我已标记删除此问题,因为我在另一个 SO link Retrieving Web Session from a POJO Outside the Web Container 中找到了答案。由于到现在还没有被删除,所以我在回答我自己的问题。

什么是 servlet 以及我们为什么使用它们?

Java servlet 是一个 Java 扩展服务器功能的程序。 尽管 servlet 可以响应任何类型的请求,但它们最常实现托管在 Web 服务器上的应用程序。 此类 Web servlet 是 Java 与其他动态 Web 内容技术(例如 PHP 和 ASP.NET.

的对应物

有关 java servlet 的更多信息位于 link https://en.wikipedia.org/wiki/Java_servlet

Servlet vs POJO/normal Java classes(为什么只在 servlet 中访问会话?)

servlet class 也是 java class。 Servlet 是一个java class 符合servlet 规范的,所以它可以运行 在服务器中。 Java class 不需要遵守 Java Servlet API

servlet 容器(例如 Tomcat)旨在能够识别 servlet classes,如果配置正确,将以特定方式处理它们。这没什么神奇的——你总是可以编写自己的应用程序,以特定方式处理任何类型的 class——但是有一个所有 servlet 容器都遵循的标准,这意味着你可以编写一个 servlet class并知道它将如何使用。

Java 被设计成一种独立于平台的语言,用于创建嵌入各种消费者的软件 电子设备。很快,由于其固有的可移植性,Java 可以在 client/server 编程环境中使用。因此在 java 中引入了 servlet 和 applet。 Java 小程序帮助在客户端创建动态的、自执行的程序。 Java servlet 是在服务器上执行的一个小程序。正如 applet 动态扩展 Web 浏览器的功能一样,servlet 动态扩展 Web 服务器的功能。

由于 java 的 servlet 部分用于服务器端编程,因此可以访问会话。 POJO classes 也用于服务器端编程,但使用会话的代码通常用 servlet 编写。

POJO 与 PHP classes(服务器端)

Java 用于许多开发环境,如桌面、移动、嵌入式和 Web。 PHP 是为 web development.It 设计的服务器端脚本语言,也可用于通用编程,但我将讨论限制在服务器端 php 中使用的 class编程(即 .php 页)。因此,最好将 php 页面中的 php class 与 servlet/JSP - JAVA 的服务器端开发部分进行比较。

再次,servlet 将 html 代码放入 Java 代码中。 JSP 将 java 代码放入 html 代码中。因此 java 中的 JSP 与 PHP 更具可比性。 如果我们理解这一点,那么我们可以推断没有充分的理由将 java 中的 POJO 与 PHP classes(服务器端)进行比较。这就像比较适用于橙子。如果您对 php 和 jsp 之间的比较感兴趣,请访问 http://www.withoutbook.com/DifferenceBetweenSubjects.php?subId1=57&subId2=2&d=Difference%20between%20PHP%20and%20JSP

在现代网络开发中,我们使用模板引擎,即我们使用带有模板引擎(Freemarker、Velocity)的 servlet 而不是 JSP。 PHP 有自己的模板引擎。

如何在 POJO classes 中访问会话?为什么很难/有什么简单的方法吗?

首先,不应该这样做,因为这将是一种糟糕的编程习惯。其次,它可以做到,但几乎没有任何情况需要这样做。由于不需要相同的方法来实现它并不容易。

不应该这样做,如果必须这样做,有两种方法。

  1. 我们可以将会话和请求对象从 servlet 传递到 POJO classes(通过方法或构造函数)。
  2. 将请求存储在过滤器的 ThreadLocal 中(然后清理它)

另请查看示例代码的 SO links

Retrieving Web Session from a POJO Outside the Web Container

当我遇到一个特定的场景时,我问了这个问题。我曾经在 PHP 中编程,想知道为什么我从来没有在那里遇到过问题并且感到困惑。通常从 php 移动到 java 的人也很难理解它是如何工作的,所以在答案中再附上一部分。

为什么 servlet 需要像 tomcat 这样的 servlet 容器,而 php 运行s 在 http server/webserver (Apache) 上?

问题的假设不正确,但答案会突出显示原因。

网络服务器是帮助向客户端(例如网络浏览器)传送网络内容(网页)的软件 通过 Internet 使用 HTTP 协议。 HTTP 是支持大多数 Web 的简单请求/响应协议 网上的应用,不管写的是不是Java。一个HTTP请求可以对应 七种 HTTP 方法之一:GET、POST、HEAD、OPTIONS、TRACE、PUT 和 DELETE

JSP/Servlets、ASP 和 PHP 等服务器端技术需要安装其软件库 在服务器上。如果没有这些库,Web 服务器将无法执行这些服务器技术,而只是一个 HTTP 服务器。 HTTP 服务器可以处理 HTML 和其他不需要任何服务器功能的客户端技术。 Apache HTTP 服务器是 HTTP 服务器的一个示例。

关于 Servet/JSP : Servlet 可以 运行 在 servlet 上 container.Tomcat 通常称为 servlet container.A Servlet 容器基本上是 [=100= 的 Web 服务器] Servlet 和 JSP 页面。 Tomcat 内部有一个 HTTP 侦听器,但除此之外它还有一个 servlet/JSP 引擎。一个servlet,说到底就是一个Javaclass。 JSP 文件(与 PHP 和较旧的 ASP 文件类似)生成 Java 代码 (Servlet),然后编译为 .class文件由服务器并由 Java 虚拟机执行。

关于 PHP :PHP 不能在纯 Apache 或任何 HTTP 服务器中工作。我们能够在 apache 中 运行 php 因为它是 linked 到 Apache(SAPI - 服务器 API) 使用 mod_php5.so( 或者类似)模块。我们通常不会启动任何 php 守护进程。 Apache 启动 php 解释器和它自己。

如果 oracle 需要,它可以开发一个类似于 PHP 模块的模块,这将使在 HTTP 服务器上托管 Java 代码变得更加容易。但是与 PHP 解释器模型相比,使用 servlet 容器模型有很多好处,即使存在复杂性增加的缺点。