在某种程度上，我正在做一些与这篇文章非常相似的内容：how to serve dynamic content in playframework 2
我有一个网络应用程序，客户可以指定各种参数，我们有Play！服务器启动一个生成自定义图像文件的进程...然后需要将其提供给该客户端，最好是通过Play！
预期的图像预期寿命可能是几秒到几分钟（甚至几小时）。从这个角度来看，我们有理由相信尝试直接使用响应发回图像数据并不是一种可行的方法......而是将向该动态图像发回一个URL。
出于各种原因，我也非常强烈不愿意依赖设置单独的HTTP服务器来提供这些动态图像。我相信原因很多，包括但不限于......为开发人员工作环境和生产服务器维护一个更简单的架构。我们有一个非常小/受限制的用户群，很少有并发用户（我不认为提供这些图像需要非常高的性能 - 假设Play！可以提供这些动态图像，我发现很难想象考虑到简单性权衡，性能不是完全可以接受的。
我读过Play！ public / folder中的资源被编译成.jar文件构建/编译时间，这似乎解释了为什么我的动态图像生成和服务测试不能按预期工作 - 返回的结果总是来自之前的构建。 / p>
任何人都可以建议一种在不依赖其他服务器的情况下重新提供动态资产的方法吗？
答案 0 :(得分：0)
无论这是否是一个好主意，Play都没有真正的问题！提供公共/文件夹中的资产。
唯一可能导致它看起来不起作用的是，在编译应用程序时已经存在于public /文件夹中的任何资产都将被编译为.jar文件。如果您编写的新文件的名称/路径与编译到该.jar文件中的名称/路径匹配，则只需返回已编译的文件，而不是新文件。如果.jar中不存在该文件，则会将其恢复正常。
这可能不是一个非常好的主意，但我认为这是我们试图做的可接受的解决方案。