参数化“静态”的好方法是什么？ Tomcat web 应用程序中的内容（例如 CSS）？
我们的一些 CSS 文件包含的参数可能会因部署位置（开发、QA、产品）而异。例如：
background: url(#DOJO_PATH#/dijit/themes...)
避免对特定 CDN 或本地托管的 Dojo 安装的路径进行硬编码。
当部署脚本将 webapp 的内容复制到 Tomcat webapps 目录中时，这些值在文本上被替换为实际值。这样，可以将相同的部署存档文件（包含其他配置的 WAR + TAR 文件）部署到 dev、QA 和 prod，并使用特定于环境的配置文件提供的不同参数。
然而，我想让 WAR 的内容（包括模板化 CSS 文件）独立于这个内部部署脚本。由于我们实际上无法控制部署脚本，所以我能想到的就是在应用程序的 context.xml 中使用 #DOJO_PATH# 等配置 Tomcat 作为环境变量，并使用 Tomcat 插入这些参数在运行时传入 CSS。
我可以将 CSS 文件制作成生成的 JSP，但对我来说似乎有点难看。而且，每次应用程序部署时只需执行一次替换，因此使用 JSP 重复动态生成样式表将相当浪费。
有没有人有任何替代的想法或工具可以用于此目的？我们致力于 Tomcat 并在部署或运行时（即不是在构建时）替换这些参数。
Some of our CSS files contain parameters that can vary based on the deployment location (dev, QA, prod). For example:
background: url(#DOJO_PATH#/dijit/themes...)
to avoid hardcoding a path to a particular CDN or locally-hosted Dojo installation.
These values are textually substituted with the real values by a deployment script, when it copies the contents of the webapp into the Tomcat webapps directory. That way the same deployment archive file (WAR + TAR file containing other configuration) can be deployed to dev, QA, and prod, with the varying parameters provided by environment-specific configuration files.
However, I'd like to make the contents of the WAR (including the templatized CSS files) independent of this in-house deployment script. Since we don't really have control over the deployment script, all I can think to do is configure Tomcat with #DOJO_PATH# etc. as environment variables in the application's context.xml, and use Tomcat to insert those parameters into the CSS at runtime.
I could make the CSS files into generated JSPs, but it seems a little ugly to me. Moreover, the substitution only needs to be done once per application deployment, so repeatedly dynamically generating the stylesheets using JSP will be rather wasteful.
Does anyone have any alternative ideas or tools to use for this? We're committed to Tomcat and to substituting these parameters at deployment or at runtime (that is, not at build time).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你现在所做的对我来说似乎是最好的解决方案。
您可以轻松地编写这些文件以由 Servlet 提供服务，并使用一些视图渲染技术（例如 Freemarker）动态替换它们的内容（或者甚至使用自定义编写的模板系统来替换关键字，但这样做会产生相关成本）
。如果这些资源在运行时真正是静态的，则可以更有效地提供这些资源。此外，如果您在 Tomcat 服务器前面使用 Apache，那么您可以让 Apache 提供静态内容，而无需访问您的 Tomcat 服务器，从而使您的 JVM 线程池更小、高度更低。争辩道。
What you're doing at the minute seems like the best solution to me.
You could easily write these files to be served by a Servlet and dynamically replace the contents of them using some view rendering technology such as Freemarker (or even a custom written templating system to replace the keywords, but there are costs associated with doing so.
Tomcat can serve these resources much more efficiently if they are truly static at runtime. Also if you front your Tomcat server with Apache then you can have Apache serve the static content without ever hitting your Tomcat server, thus keeping your JVM thread pool smaller and less highly contended.
您还可以有一个指向特定于环境的配置文件的环境变量，并让一些启动脚本在此时将其插入在一起。这样，命令行就不会失去控制。
You could also have a single environment variable that pointed at an environment-specific configuration file, and have some startup scripts plug it together for you at that point. That way, the command line doesn't get out of control.