阿帕奇 FOP 和Java 热启动选项（使用 Rhino 效果更好）
这是我需要做的：在服务器（最好是 Windows）上使用 Apache 的 FOP 渲染 PDF。作业将来自队列，但这并不是太重要。
我希望避免每次需要渲染作业时都预热 JVM。 FOP 有一个参考 servlet，我可以将其用于 Web 请求，但我不想介绍 Tomcat。
我有非常粗糙的 Java 技能（并且希望保持这种状态），所以，启动一个长时间运行的 Java 程序的最简单方法是什么，该程序可以监视队列并运行 FOP 作业，而不会产生启动开销比如说，命令行 Java 脚本？我很乐意使用 Rhino 来完成此操作，因为我对 JS 很熟悉，并且已经在 Rhino/JS 中掌握了很多文档处理逻辑。我绝对不想使用 Java Web 服务器。
Here is what I need to do: Render PDFs using Apache's FOP on a server (preferably Windows). The jobs will come from a queue, but that's not too important.
I want to avoid warming up the JVM each time I need to render a job. FOP has a reference servlet that I could use with web requests, but I don't want to introduce Tomcat.
I have very rough Java skills (and would prefer to keep it that way) so, what's the easiest way to start a long-running Java program which can monitor a queue, and run FOP jobs, without the start-up overhead that happens with, say, a command line Java script? I would love to do this with Rhino, since I'm comfortable with JS, and already have a lot of the document processing logic in Rhino/JS. I definitely don't want to use a Java web server.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为你只有两个选择；
Java“服务器”，无论是 Web 服务器还是 RPC 服务器。我们使用 thrift 与长期运行的 java 服务进行通信，该服务的唯一目的是生成 PDF。我们在启动时预加载 FOP，并为每个请求保持库“热”。 Web 服务也同样好。
一个java守护进程，它监听你提到的队列，生成PDF（也许把它放在tmp文件夹中？）并返回完成通知和另一个队列的位置（这实际上是我们生成长队列的方式）运行超过 300 页的财务报告）。
您可以使用任何您想要的语言；如果 Rhino 可以直接与 Java/FOP 通信，那么就不会有问题。我们在 Java 之上的各种项目中使用了 Jython 和 Scala。
I think you only really have two options;
A java "server", whether it be a web server or an RPC server. We use thrift to communicate with a long-running java service who's only purpose is to generate PDFs. We pre-load FOP at start-up and keep the library "hot" for each request. A web service would be just as good.
A java daemon which listens to the queue you mentioned, generates the PDF (putting it in the tmp folder, maybe?) and returns a notification of completion and location on another queue (this is actually how we work for generating long-running financial reports with > 300 pages).
You could use whatever language you want; if Rhino can communicate to Java/FOP directly you shouldn't have a problem. We've used Jython and Scala for various projects on top of Java.