servlet要写入的可接受位置？

我想在运行在Tomcat上的基于servlet的应用程序中嵌入一个Derby数据库。servlet要写入的可接受位置？

为此，我需要将数据库文件保存在磁盘上。我希望他们驻留在已部署的Web应用程序的子文件夹中（然后我可以使用getServletContext().getRealPath()进行转换）。

是否有一个很好的做法WRT可以接受的，相对于应用程序的位置，其中一个servlet可以安全地写？如果不存在这样的建议，那么tomcat特定的良好实践是什么？

This discussion似乎排除WebContent写作;我将不得不写一个CATALINA_HOME子文件夹，因为一些教程指出（但它感觉hackish）？

2012-12-07 oparisy

至于'getRealPath（）'的事，这是不好的，因为你没有做任何更改将丢失时，你重新部署WAR甚至当你重新启动其自动重新部署现有的WAR服务器。简单的原因是这些更改根本不包含在原始WAR中。 – BalusC

你需要让文件系统的持久性位置明确的参数到您的程序，可能是一个属性（即-DdataStoreLocation=somepath）。通常，Java应用程序可能有权访问文件系统 - 它可以从WAR内运行，甚至可以从网络加载并且没有类路径相关的文件系统。

让它成为您的应用程序与用户合同的明确要求，部分是为了保证有一个文件系统使用，一种方式来获得的路径名称中使用的唯一途径。

来源

2012-12-08 04:24:00

好的，所以你的答案是“否”：没有通用的文件系统位置Servlet可以写入存在。所以我应该坚持一个数据源（如你所建议的那样，在部署时报告位置/配置选择），或者仍然能够使用嵌入式数据库，将它的文件系统位置作为参数传递（我可以使用'server .xml'？JNDI？）。 – oparisy

我看到一个[Context]（http://stackoverflow.com/a/1626190/38096）可以做到这一点。 – oparisy

可能没有文件系统，但不太可能。 Context是Java应用程序可以与其环境交互的另一种方式，如果该环境是应用程序服务器。有一个系统属性'java.io.tmpdir'用于临时文件系统资源，但不能保证放置在那里的东西将无限期地保存下来。由于您具体询问servlet，所以Context是提供路径信息的好地方。 –

当你安装一个应用程序时，你宁愿看到你的数据存储在/usr/bin（或C:/Program Files）的某个地方，或者更确切地说你的主目录中的其他数据在哪里？

不耦合的应用程序二进制文件（这永远不会改变），用它操作的数据。删除应用程序时不希望丢失数据，反之亦然。用户主目录甚至更好 - 在安装过程中选择的文件夹 - 要好得多。

来源

2012-12-07 22:56:27

如何在服务器部署的应用程序的上下文中定义“用户主目录”？我明白不写入WebContent确实是由于重新部署导致删除的风险。 – oparisy

servlet要写入的可接受位置？

回答

相关问题