blocks|key|1430867|text|这在很大程度上取决于web应用服务器提供给您的选项。我们有多个使用不同JDBC+URL的JBoss环境，所有服务器上的JNDI名称都保持不变，只是本地实例上的配置发生了变化，所以不同版本之间没有任何问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1430868|我想简短的答案是，最好的做法是将配置外部化，并为每个服务器保存一个包含正确设置的良好文件，然后让web应用程序读取该配置。外部化和读取的确切性质将取决于特定的配置和应用程序服务器。|1430869|编辑:这些配置并不作为war+(在我们的例子中是ear)的一部分存在，因此它们不会被覆盖。|1430870|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

This is heavily going to depend on what options the web application servers give you. We have multiple environments for JBoss with different JDBC URLs, the JNDI name remains the same across all servers, just the configuration on the local instance changes, so nothing goes wrong from build to build.

I guess the short answer is that the best practice is to externalize the configurations and keep a good file in place with the correct settings for each server, and have the web app read that configuration. The exact nature of the externalization and reading is going to depend on the specific configuration and application server.

EDIT: These configurations do not exist as part of the war (ear in our case) that way they are not overwritten.

blocks|key|1216062|text|首先，将经常更改的所有配置设置放在一个位置。如果您需要同时设置JNDI、编辑数据库值和修改属性文件，以完成配置，那么这真的很困难。请选择最易于编辑且更易于验证所有内容是否正确设置的介质。我想说属性文件是最好的解决方案。你可以很容易地编辑它们，你只需要快速浏览一下它们就可以看到一切都是正常的。如果您选择属性文件，请仔细为它们选择一个标准位置，并为路径分配一个环境变量。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1216063|如果您有一个简单的测试来验证所有设置是否正确，这也会有所帮助。例如，您可以有一个显示配置参数并执行一些基本测试的测试页面，比如尝试连接到数据库或远程服务器。|1216064|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

At first have all the configuration settings that frequently change in one place. It is really difficult, if you need to set up JNDI, edit database values and modify property files, all at the same time, in order to complete the configuration. Prefer the medium that is easiest to edit and also easier to verify that everything is set up properly. I would say that property files is the best solution. You can easily edit them and you only need a quick look through them to see that everything is alright. If you opt for property files, carefully select a standard location for them and assign an environmental variable for the path.

It also helps if you have a simple test that verifies that everything is set up properly. For example you can have a test page that displays the configuration parameters and performs some basic tests, like trying to connect to database or remote servers.

blocks|key|1430990|text|我们所做的工作非常好用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1430991|在启动时，我们的程序读取硬编码路径中的配置文件。假设它是：|1430992|/config/fun_prog/config.xml|code-block|syntax|javascript|1430993|每个程序都有不同的硬编码路径(FunProgram在fun_prog中，超级服务器在sup_serv中，等等)，所以我们不必担心它们会相互碰撞。|1430994|XML文件由我们创建的一个小配置库读取。XML文件包含数据库连接信息，通常是邮件服务器配置数据、要向其发送通知的电子邮件地址、是否应在测试模式下运行、外部服务的URL等。|1430995|因此，当我们需要进行更改时，我们复制配置文件，编辑我们想要的内容，然后重新启动程序。因为我们有一个标准的服务器设置，所以只要复制这些文件(以及必要的httpd.conf修补)，就可以在任何服务器上部署任何程序。|1430996|这并不花哨，但它工作得很好。它非常容易理解、添加新的配置选项、备份和编辑。在所有平台上都可以工作(unix很明显，Windows将以/开头的路径转换为c:\，所以它也可以在没有编辑的情况下工作)。|1430997|我们的工作站基本上运行与服务器相同的软件，只是在配置文件中做了一些更改。|1430998|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

What we do works pretty well.

On startup, our programs read a configuration file in a hardcoded path. Let's say it's:

<pre><code>/config/fun_prog/config.xml
</code></pre>

Each program has a different hard coded path (FunProgram is in fun_prog, Super Server is in sup_serv, whatever), so we don't have to worry about them walking over each other.

The XML files are read by a little configuration library we created. The XML file contains the DB connection information, usually mail server configuration data, email addresses to send notifications to, whether it should operate in test mode, URLs of external services, etc.

So when we need to make changes, we copy the config file, edit what we want, and restart the program. Since we have a standard server setup, any program can be deployed on any server by just copying these files around (and the neccessary httpd.conf tinkering).

It's not fancy, but it works very well. It's extremely simple to understand, add new configuration options, backup, and edit. Works on all platforms (unix is obvious, Windows translates paths starting with / into c:\ so it works without edits there too).

Our workstations basically run the same software as the server, just with a few changes in that config file.

blocks|key|1431075|text|您需要的好例子是在Seam或Grails中使用(借用自Rails)。有一些配置文件，默认情况下有三个:+prod、dev、test，但如果需要，您可以定义更多。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1431076|在Seam中，项目的构建是由Ant文件完成的。为每个配置文件定义内容可以变化的每个文件，例如数据源、sql脚本或属性文件。|1431077|import-dev.sql|style|CODE|1431078|import-prod.sql|1431079|import-test.sql|1431080|当ant文件使用选定的配置文件运行时，将采用适当的文件，并从该文件名中截断配置文件名。|1431081|下面是您可以放在目标中的代码片段|1431082|<copy+tofile="${war.dir}/WEB-INF/classes/import.sql"+
++++++file="${basedir}/resources/import-${profile}.sql"/>|code-block|syntax|javascript|1431083|JDBC+url，驱动程序名称可以外部化到属性文件中(当然可以使用配置文件名称作为后缀)。|1431084|<filterset+id="persistence">
+++++<filter+token="transactionManagerLookupClass"+value="${transactionManagerLookupClass}"/>

<copy+tofile="${war.dir}/WEB-INF/classes/META-INF/persistence.xml"+
+++++file="${basedir}/resources/META-INF/persistence-${profile}.xml">
+++++<filterset+refid="persistence"/>
</copy>|1431085|或者您可以从命令行传递给ant+build调用的属性的值。这是Seam中所做的简短示例。|1431086|另一种选择是使用Maven。在maven中，它是通过属性和profiles来完成的，但你也可以使用单独的模块来拆分配置，并创建具有主要功能的其他模块。maven属性和配置文件的典型用例示例是多个数据库、部署服务器等的运行配置。当您想要为不同的供应商创建配置时，这会更加困难，但对于Maven来说这不是问题:)|1431087|使用maven配置文件的一个很好的例子是这个帖子表单Carlos+Sanchez+blog。|1431088|总而言之，我强烈建议查看Ant/Seam和Maven参数化(配置文件)。这些解决方案还有另一个优势:+ant或maven脚本可以在CI服务器(如Hudson)中运行，并允许同时运行/测试所有配置文件。|1431089|entityMap|0|LINK|mutability|MUTABLE|url|http://seamframework.org/|1|http://maven.apache.org/|2|http://www.sonatype.com/books/maven-book/reference/profiles.html|3|http://www.jroller.com/carlossg/entry/functional_testing_with_maven_cargo|4|http://hudson-ci.org/^0|9|4|0|0|0|0|E|0|0|F|0|0|F|0|0|0|0|0|0|0|8|5|1|T|8|2|0|Q|J|3|0|20|6|4|0^^$0|@$1|2|3|4|5|6|7|1O|8|@]|9|@$A|1P|B|1Q|1|1R]]|C|$]]|$1|D|3|E|5|6|7|1S|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1T|8|@$A|1U|B|1V|H|I]]|9|@]|C|$]]|$1|J|3|K|5|6|7|1W|8|@$A|1X|B|1Y|H|I]]|9|@]|C|$]]|$1|L|3|M|5|6|7|1Z|8|@$A|20|B|21|H|I]]|9|@]|C|$]]|$1|N|3|O|5|6|7|22|8|@]|9|@]|C|$]]|$1|P|3|Q|5|6|7|23|8|@]|9|@]|C|$]]|$1|R|3|S|5|T|7|24|8|@]|9|@]|C|$U|V]]|$1|W|3|X|5|6|7|25|8|@]|9|@]|C|$]]|$1|Y|3|Z|5|T|7|26|8|@]|9|@]|C|$U|V]]|$1|10|3|11|5|6|7|27|8|@]|9|@]|C|$]]|$1|12|3|13|5|6|7|28|8|@]|9|@$A|29|B|2A|1|2B]|$A|2C|B|2D|1|2E]]|C|$]]|$1|14|3|15|5|6|7|2F|8|@]|9|@$A|2G|B|2H|1|2I]]|C|$]]|$1|16|3|17|5|6|7|2J|8|@]|9|@$A|2K|B|2L|1|2M]]|C|$]]|$1|18|3|-4|5|6|7|2N|8|@]|9|@]|C|$]]]|19|$1A|$5|1B|1C|1D|C|$1E|1F]]|1G|$5|1B|1C|1D|C|$1E|1H]]|1I|$5|1B|1C|1D|C|$1E|1J]]|1K|$5|1B|1C|1D|C|$1E|1L]]|1M|$5|1B|1C|1D|C|$1E|1N]]]]

The good example what you want is used in <a href="http://seamframework.org/" rel="nofollow noreferrer">Seam</a> or Grails (borrowed from Rails). There are profiles, by default three: prod, dev, test, but you can define more if you want. 

In Seam project build is done by Ant files. Eeach file that contents can vary is defined for every profile e.g. datasource, sql scripts or properties files.

<code>import-dev.sql 
 import-prod.sql 
 import-test.sql</code>

When ant file is run with choosen profile, appropriate file is taken and profile name is truncated from that file name. 

Below is code snippet that you can place in your targets

<pre><code>&lt;copy tofile="${war.dir}/WEB-INF/classes/import.sql" 
 file="${basedir}/resources/import-${profile}.sql"/&gt;
</code></pre>

JDBC url, driver names can be externalized to properties files (of course with profile names as suffixes)

<pre><code>&lt;filterset id="persistence"&gt;
 &lt;filter token="transactionManagerLookupClass" value="${transactionManagerLookupClass}"/&gt;

&lt;copy tofile="${war.dir}/WEB-INF/classes/META-INF/persistence.xml" 
 file="${basedir}/resources/META-INF/persistence-${profile}.xml"&gt;
 &lt;filterset refid="persistence"/&gt;
&lt;/copy&gt;
</code></pre>

or values of properies you can pass to ant build call from command line. This is short example what is in Seam done.

Another option is to used <a href="http://maven.apache.org/" rel="nofollow noreferrer">Maven</a>. In maven way it done by properties and by <a href="http://www.sonatype.com/books/maven-book/reference/profiles.html" rel="nofollow noreferrer">profiles</a>, but you can use also separate modules to split configuration and create other modules with main functionality. Typical use case examples of maven properties and profiles are run configuration for multiple databases, deployment servers etc. It's even harder when you want to create configuration for different vendors, but for Maven that isn't a problem :)

Great example of using maven profiles is this post form <a href="http://www.jroller.com/carlossg/entry/functional_testing_with_maven_cargo" rel="nofollow noreferrer">Carlos Sanchez blog</a>.

To sum up I strongly recomend to look up Ant/Seam an Maven parametrization (profiles). Those solutions have another advantage: ant or maven script can be run in CI server (like <a href="http://hudson-ci.org/" rel="nofollow noreferrer">Hudson</a>) and let run/test simultaneously all your profiles.

blocks|key|1431169|text|我很惊讶没有人引用Jakarta+Commons+Configuration+API+(http://commons.apache.org/configuration/)来回答这个问题。它允许您拥有文件的层次结构(或其他配置源，如XML、JNDI、JDBC等)。这就是Jeremy+Seghi所说的，它为您提供了一种同时具有默认值和本地覆盖的好方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1431170|最好的部分是它是一个经过测试的工作解决方案，所以你不需要自己去制作一些东西。|1431171|entityMap|0|LINK|mutability|MUTABLE|url|http://commons.apache.org/configuration/^0|18|14|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

I'm surprised that no one cited the Jakarta Commons Configuration API (<a href="http://commons.apache.org/configuration/" rel="noreferrer">http://commons.apache.org/configuration/</a>) to answer this question. It allows you to have a hierarchy of files (or other configuration sources like XML, JNDI, JDBC, etc.). That's what Jeremy Seghi was talking about and it gives you a good way to have both defaults and local overrides as well.

The best part is that it is a tested working solution so you don't have to go craft something yourself.

blocks|key|1216410|text|请查看以下网址：http://issues.apache.org/jira/browse/CONFIGURATION-394|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1216411|我们正在寻找的配置框架是在Apache+Commons配置之上的东西，并且必须支持并发问题、JMX问题和大多数存储(例如.properties文件、.xml文件或PreferencesAPI)。|1216412|weblogic团队在“管理控制台”上提供的是兴趣，通过它，您可以对配置进行事务(原子)更新，以便已注册的侦听器得到通知。|1216413|Apache的人坚持认为这个项目可能超出了Commons的配置范围！|1216414|我已经附上了一个简单的配置框架，请看。|1216415|entityMap|0|LINK|mutability|MUTABLE|url|http://issues.apache.org/jira/browse/CONFIGURATION-394^0|8|1I|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@]|C|$]]|$1|L|3|-4|5|6|7|11|8|@]|9|@]|C|$]]]|M|$N|$5|O|P|Q|C|$R|S]]]]

Please take a look at this URL: <a href="http://issues.apache.org/jira/browse/CONFIGURATION-394" rel="nofollow noreferrer">http://issues.apache.org/jira/browse/CONFIGURATION-394</a>

The Configuration framework which we're looking for it is something on top of Apache Commons Configuration and must support Concurrency Issues, JMX issues and most of stores(e.g .properties file, .xml files or PreferencesAPI).

What weblogic team provides on 'Administration Console' is intersting which through it you can have transactional(atomic) updates on configurations so that are registered listeners be notified.

The Apache guys insist that this project is out of scopes of Commons Configuration, maybe!

I've attached a simple configuration framework, take look please.

blocks|key|1431333|text|您可以在您选择的语言中使用组件配置模式|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1431334|这在POSA的书中有描述(我想在第四卷)|1431335|(在java中，您可以使用commons-configuration组件)。|offset|length|1431336|entityMap|0|LINK|mutability|MUTABLE|url|https://commons.apache.org/proper/commons-configuration/^0|0|0|D|L|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

You can use the Component Configuration Pattern in your language of choice 

It is described in the POSA books (I think that in the 4th volume)

(in java you can use the <a href="https://commons.apache.org/proper/commons-configuration/" rel="nofollow">commons-configuration</a> component ).

Are there any patterns or best practices that can be used to simplify changing configuration profiles for java web applications across multiple environments. e.g. JDBC URLs, SOAP end-points, etc. 

As a bit of background to help clarify my question, I work with several large java web applications that during any given release cycle move through 6 different environments; development, integration, QA, performance and eventually get deployed to multiple production servers. In each environment, configuration needs to change. Right now, most configuration changes for each deployment are done manually which is both time consuming and open to errors. 
Is there any way to take the manual intervention out of this process?

Java Web Application Configuration Patterns

数据库

服务器

Windows

是否有任何模式或最佳实践可用于简化跨多个环境的java web应用程序配置文件的更改。例如JDBC URL、SOAP端点等。作为一些背景知识来帮助澄清我的问题，我使用了几个大型的java web应用程序，它们在任何给定的发布周期中经历了6个不同的环境:开发、集成、QA、性能，并最终部署到多个生产服务器上。在每个环境中，...

问Java Web应用程序配置模式
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java Web应用程序配置模式EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java Web应用程序配置模式
EN