1

在某种程度上，我正在做与这篇文章非常相似的事情： 如何在 playframework 2 中提供动态内容

那就是我有一个网络应用程序，客户可以在其中指定各种参数，我们有 Play！服务器启动一个生成自定义图像文件的过程......然后需要将其返回给该客户端，最好由 Play！

预期的图像预期寿命可能从几秒到几分钟（甚至几小时）不等。从这个角度来看，我们有理由相信，尝试直接将图像数据与响应一起发回并不是一种可行的方法……而是将一个 URL 发回该动态图像。

由于各种原因，我也非常希望不依赖于设置单独的 HTTP 服务器来提供这些动态图像。我相信原因很多，包括但不限于……为开发人员的工作环境和生产服务器维护一个更简单的架构。我们的用户群非常小/受限，并发用户很少（我不认为提供这些图像需要非常高性能 - 假设 Play! 可以提供这些动态图像，我发现很难想象考虑到简单性的权衡，性能不会完全可以接受）。

我读过那部戏！public/ 文件夹中的资产被编译成一个 .jar 文件构建/编译时间，这似乎解释了为什么我的动态图像生成和回送测试没有按预期工作 - 回送的结果总是来自以前的构建。

任何人都可以建议一种在不依赖另一台服务器的情况下提供动态资产的方法吗？

4

1 回答 1

0

不管这是否是一个好主意，Play 都没有真正的问题！在 public/ 文件夹中提供资产。

唯一可能导致它看起来不起作用的是，当应用程序被编译时，任何已经存在于 public/ 文件夹中的资产都将被编译成一个 .jar 文件。如果您编写一个名称/路径与编译到该 .jar 文件中的文件匹配的新文件，您只需返回已编译的文件，而不是新文件。如果 .jar 中不存在该文件，则将其返回就可以了。

这可能不是一个非常好的主意，但我认为这对于我们正在尝试做的事情来说是一个可以接受的解决方案。

于 2013-05-16T01:41:20.110 回答