在一定程度上，我做的非常相似，这篇文章的内容： 如何提供动态内容的playframework 2
这是，我有一个web应用程序，在这里客户可以指定各种参数和我们有玩游戏！ 服务器发起生成的自定义图像文件...然后还需送达回客户端，最好通过娱乐的过程！
预期图像预期寿命可能从几秒钟到几分钟（甚至小时）的任何地方。 从这个角度，我们有理由相信，尝试将图像数据直接发送响应回是不是一种可行的方法......，而是要一个URL发回给动态图像。
我也很强烈倾向于不依赖于一个单独的HTTP服务器被设置为提供了这些动态图像的各种原因。 我认为，原因是多方面的，包括但不限于......维护更简单的架构同时为开发人员的工作环境以及生产服务器。 我们有很少的并发用户一个非常小的/受限制的用户群（我不相信服务了这些图像需要有非常高的性能呢！ - 假设游戏能容纳这些动态画面，我很难想象，性能也不会完全可以接受的考虑简单的折衷）。
我读过，玩游戏！ 在公共/文件夹资产被编译成一个.jar文件编译/编译时间，这似乎解释了为什么我的动态图像生成和服务早在预期不工作的测试 - 结果送达回总是从以前的版本。
任何人都可以提出服务的动态资产回不依靠另一台服务器上的方法吗？
