Java EE 程序员不写入文件答案

【问题标题】：Java EE programmers do not write to filesJava EE 程序员不写入文件
【发布时间】：2009-11-24 11:54:37
【问题描述】：

今天有人告诉我“Java EE 程序员不写入文件”。为什么我不能从 Java EE 容器（例如从 JBoss）中写入文件？怎么了？

【问题讨论】：

标签： java jakarta-ee jboss

【解决方案1】：

您应该在 Java EE 容器内完成所有操作：您无法确定您是否能够始终如一地访问文件系统。这有很多原因，最明显的是在容器中运行的应用程序会：

不确定 EJB 的任何后续调用会甚至在同一物理服务器上访问同一文件/文件系统（例如在集群中）
不可能相互干扰（多个应用程序尝试写入同一个文件）
没有安全问题（一个应用程序写入另一个应用程序可以读取的机密数据）

你还应该假设你不应该：

创建您自己的线程（容器将为您管理这些；如果您创建自己的线程，您可能会占用容器中的其他应用程序的 CPU 时间）
使用 socket-IO（也有安全问题）

【讨论】：

【解决方案2】：

最好看的页面是这个：http://www.oracle.com/technetwork/java/restrictions-142267.html

它详细介绍了 Java EE 编程模型的限制。

除了上面提到的安全性、可移植性、集群、线程之外，还要考虑事务和错误处理（文件系统不是事务性的）。

然而，JVM 中并没有发生什么黑魔法，你可以创建文件（只要你有相应的权限），使用静态变量，如果你知道自己在做什么，还可以创建线程。

最好花时间了解为什么通常会建议这些限制，而不是为了合规而跳过并编写 JCA 连接器。

【讨论】：

虽然可能没有“黑魔法”，但容器的 JVM 安全管理器可能已设置为无法创建文件
@BorisŠuška 此链接看起来与原始链接非常相似：oracle.com/technetwork/java/restrictions-142267.html

【解决方案3】：

即使您可以访问文件系统，对于分布式系统，您也无法确定下次调用方法时，它会在写入文件的同一台机器上处理。

【讨论】：

【解决方案4】：

根据 Java EE 规范，严格禁止 EJB 通过“资源管理器”（JDBC、JNDI、JCA 等）以外的任何方式访问任何外部资源，这尤其包括通过以下类访问本地文件系统java.io 包。此外，ClassLoader 也不能用于此类访问，例如从应用程序的类路径加载属性文件。

原因已经在其他答案中给出：

安全问题
可移植性问题
集群问题
线程问题

最终，解决这些问题的最佳资源是数据库。

【讨论】：

【解决方案5】：

如果您的实例不是集群的，或者可以保证所有实例都可以使用网络驱动器，那么使用 File apis 读取/写入文件就不是问题。然而，必须注意使路径正确并酌情清理。通常没有任何实际需要编写文件，所以再考虑一下。大多数人给出的主要原因是，在集群中，不同的服务器不会看到相同的文件，因为路径发生了变化等等。最后大多数小应用程序都不会在这样的集群中运行......

【讨论】：

【解决方案6】：

您应该将文件系统视为企业信息系统 (EIS)。然后您可以创建一个访问此 EIS 的 ResourceAdapter，类似于访问数据库的 JDBC 适配器。规范在这里：http://java.sun.com/j2ee/connector/download.html。这意味着文件访问是可能的，但要复杂得多。该规范甚至允许您创建某种称为 Work 的“线程”。

【讨论】：

【解决方案7】：

因为 Java EE 规范不提供用于写入文件的 API。当然，你可以只使用普通的 Java IO API 来创建文件，但是你必须确保这段代码是线程安全的，有人清理文件，文件名被传递给下一个 bean，文件是当您的 bean 移动到集群中的另一个节点等时迁移。

因此，虽然您可以做到，但在实践中，您会遇到很多小问题，这使得在 Java EE 中处理文件非常困难。

【讨论】：

废话 - J2EE 规范没有为很多事情提供自己的 API，例如动态生成图像。
你的意思是？如果图像生成 API 与 J2EE 兼容，那么一切都很好。当它不是并创建本地文件时，你就有麻烦了。但事实上 IO API 不符合 J2EE。

【解决方案8】：

为了与遗留的非 j2ee 系统进行互操作，您有时不得不做一些“坏事”，例如套接字 i/o、写入文件等。在最好的情况下，将遵循 j2ee 规范严格来说，但人们总是为了方便和完成工作而远离非 j2ee 的东西。有一些方法可以安全、周到地完成这些事情。

【讨论】：