我可以在多个环境中使用单个war文件吗?我是不是该?

Nob*_*Man 27 java jsp java-ee

我的工作中有一个Java Web应用程序,我想简化我们部署到DEV,QA和PROD环境的方式.

应用程序在启动时读取一系列属性,dev,qa和prod的属性文件不同.每当我想部署到某个环境时,我都会将特定于环境的属性文件放到我的app文件夹中,构建war,然后将其部署到三个tomcat 5.5服务器之一.

我想要做的是必须有一个.war,它具有所有环境的属性,并让应用程序在初始化过程中询问Web服务器,以确定应用程序所处的环境,以及要加载的属性.是否有一种简单的方法(或者,这是一种标准的方式)?

Chs*_*y76 17

这实际上取决于您使用这些属性的内容.

一些(例如数据源)可以在容器本身中配置(Tomcat 5.5.JNDI Resources,也参见JDBC sources部分).

其他(特定于应用程序)可能确实需要属性.在这种情况下,您的选择是:

  1. 捆绑WAR文件中的属性并根据某些外部开关(环境变量或JVM属性)加载适当的子集
  2. 在解压为war的每台服务器上设置部署过程,并将属性文件(位于该服务器上的预定义位置并且特定于该服务器)复制到WEB-INF/classes(或其他适当的位置).

至于"这是一个理想的目标" - 是的,我想是的.在QA /分期中测试单个WAR然后部署到生产中会减少中间步骤,从而减少出错的机会.

更新(根据评论):

上面的项目#1是指实际的环境变量(例如,您SET ENV_NAME=QA在Windows或ENV_NAME=QA; export ENV_NAMELinux中设置的内容).您可以使用代码从代码中读取其值System.getenv()并加载相应的属性文件:

String targetEnvironment = System.getenv("TARGET_ENV");
String resourceFileName = "/WEB-INF/configuration-" + targetEnvironment + ".properties";
InputStream is = getServletContext().getResourceAsStream(resourceFileName);
Properties configuration = new Properties();
configuration.load(is);
Run Code Online (Sandbox Code Playgroud)

但是,您可以改为通过JNDI定义标量值(请参阅Tomcat doc中的环境条目):

<Context ...>
  <Environment name="TARGET_ENV" value="DEV" type="java.lang.String" override="false"/>
</Context>
Run Code Online (Sandbox Code Playgroud)

并通过您的应用程序阅读它

Context context = (Context) InitialContext().lookup("java:comp/env");
String targetEnvironment = (String) context.lookup("TARGET_ENV");
// the rest is the same as above
Run Code Online (Sandbox Code Playgroud)

问题是,如果您仍将使用JNDI,您可以放弃您的属性文件并通过JNDI配置所有内容.您可以使用您的数据源作为实际资源,基本属性仍然是标量(尽管它们是类型安全的).

最终由您来决定哪种方式更适合您的特定需求; 两者都有利有弊.


fvu*_*fvu 6

你所做的是一场等待发生的事故......有一天,DEV战争将最终进入de PROD服务器,并且通过一些优于所有自然法则的法律将在凌晨2点检测到问题.无法解释为什么会这样,但有一天会发生.因此,在我看来,一场战争肯定是一个好主意.

您可以在相应的JVM中设置系统属性(-Dcom.yourdomain.configpath =/where/you/store/configfiles)并获取此属性

String value = System.getProperty("com.yourdomain.configpath", "defaultvalue_if_any"); 
Run Code Online (Sandbox Code Playgroud)

默认值可能指向战争中的某个位置(WEB-INF/...),或者如果没有默认值,则用于在加载期间发出一些记录噪声以警告错误配置).还要注意,这种技术不依赖于平台,所以你的dev机器可以是Windows机器和服务器的Linux机器,它可以应付这两者.我们通常在这个configpath中为每个应用程序创建一个子目录,因为有几个应用程序在服务器上使用这个系统,我们希望保持整洁.

作为额外的好处,您不会冒这种方式在PROD服务器上手动调整属性文件的风险.只是不要忘记在备份方案中包含文件存储的路径.