管理配置数据的最佳方法是什么

发布于 2024-08-22 12:28:23 字数 255 浏览 3 评论 0原文

我正在开发一个包含 4 个产品的产品套件。目前,所有配置数据都在 XML 或属性文件中。这种方法不可维护,因为我们必须为不同的环境(例如生产、开发等)管理不同的配置文件。

那么,处理配置数据的最佳方式是什么?

另外,我们可以将其模块化为一个单独的模块吗?这样所有的产品都可以使用这个模块。 我们不想使用属性文件。我正在寻找一种解决方案,在该解决方案中,我们可以将所有配置特定代码移动为新的配置模块,并将所有配置数据保留在数据库中。

I am working on a product suite which has 4 products. Right now, all of the configuration data is either in the XML or properties files.This approach is not maintainable as we have to manage different configuration file for different environment(for e.g. Production, Development etc).

So, what is the best way to handle configuration data?

Also, can we modularize this into a separate module? So that all products can use this module.
We don't want to use the property files. I am looking for a solution in which we can move all of the configuration specific code as a new configuration module and persist all the configuration data in database.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

離殇 2024-08-29 12:28:23

使用 commons-configuration,您可以使用统一的 API 来访问属性,无论如何 它们被表示为 - .properties、xml、JNDI 等。例如:

config.properties:

jdbcHost=192.168.12.35
jdbcUsername=dbuser
jdbcPassword=pass

config.xml

<config>
   <jdbcHost>192.168.12.35</jdbcHost>
   <jdbcUsername>dbuser</jdbcUsername>
   <jdbcPassword>pass</jdbcPassword>
</config>

在这两种情况下,它们都可以通过类似的方式访问:

String host = config.getString("jdbcHost");

Using commons-configuration you have a unified API for accessing the properties, no matter how they are represented - .properties, xml, JNDI, etc. For example:

config.properties:

jdbcHost=192.168.12.35
jdbcUsername=dbuser
jdbcPassword=pass

config.xml:

<config>
   <jdbcHost>192.168.12.35</jdbcHost>
   <jdbcUsername>dbuser</jdbcUsername>
   <jdbcPassword>pass</jdbcPassword>
</config>

in both cases they will be accessible with something like:

String host = config.getString("jdbcHost");
朮生 2024-08-29 12:28:23

你就快到了...我将保持相同的方法,并为通过类似于以下任一方法运行的应用程序实例引入正确的配置文件:

  1. 以不同的方式命名所有配置文件并让您的应用程序通过一些独特的标准(用户名、主机名等)将它们拉入:

    • 生产.properties
    • 开发人员1.properties
    • developer2.properties
  2. 将它们保留在代码库之外的基于应用程序假设存在的环境变量的位置:

    • YOURAPP_CONFIG_DIR/server_config.xml
    • YOURAPP_CONFIG_DIR/database_config.properties

我已经甚至在同一个项目中使用这些方法的组合(#1 用于构建过程配置,#2 用于运行时配置)。

You're almost there... I would keep your same approach and pull in the correct configuration file for the instance of the application that is running by a method similar to either of the following:

  1. Name all of your configuration files differently and have your application pull them in by some unique criteria (username, hostname, etc.):

    • production.properties
    • developer1.properties
    • developer2.properties
  2. Keep them outside the codebase in a location based on an environment variable that the application assumes exists:

    • YOURAPP_CONFIG_DIR/server_config.xml
    • YOURAPP_CONFIG_DIR/database_config.properties

I've even used a combination of these approaches on the same project (#1 for build process configurations and #2 for runtime configurations).

开始看清了 2024-08-29 12:28:23

如果您的应用程序使用数据库,您可以创建一个“配置”表,如下所示:

create table configuration (mode char(3), key varchar(255), value varchar(1023));

可以使用 init 脚本(例如 init.sql)初始化它,其内容如下:

insert into configuration values ('pro', 'param1', 'value1'); -- production
insert into configuration values ('dev', 'param1', 'value1'); -- development
insert into configuration values ('tst', 'param1', 'value1'); -- testing
...

这种方法的好处如下:

  • 您 脚本连同
    您的代码
  • 您可以轻松扩展 以包括
    每用户或每组设置
    添加用户/组 ID,
  • 您可以更改设置
    运行时如果您需要这样做,
  • 您可以使用相同的堆栈(JPA +
    DAO、Cayenne...)您通常用来
    处理核心应用程序数据
    处理配置数据

If your applications work with a database, you can create a "configuration" table as follows:

create table configuration (mode char(3), key varchar(255), value varchar(1023));

You would initialize it using an init script, say init.sql with contents along the lines of:

insert into configuration values ('pro', 'param1', 'value1'); -- production
insert into configuration values ('dev', 'param1', 'value1'); -- development
insert into configuration values ('tst', 'param1', 'value1'); -- testing
...

The benefits of this approach are as follows:

  • you version the script together with
    your code
  • you can easily extend it to include
    per-user or per-group settings by
    adding a user/group id
  • you can change the settings at
    runtime if you need to do so
  • you get to use the same stack (JPA +
    DAO, Cayenne...) you normally use to
    handle core application data to
    handle configuration data
柏拉图鍀咏恒 2024-08-29 12:28:23

对于我们所有的环境,配置数据以属性文件的形式存在于目标计算机上。我们使用 PropertyPlaceholderconfigurer< /a> 从 SpringFramework 将这些属性绑定到我们的应用程序,以保持跨环境的可移植性。

例如,只要我知道 /etc/myapp/database.properties 将出现在我的应用程序将运行的任何机器上,那么在我的 spring 配置中,我只需要类似这样的东西:

    <bean id="myPropertyConfigurer"
    class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="locations">
        <list>
            <value>/etc/myapp/database.properties</value>
        </list>
    </property>
</bean>
<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver" />
    <property name="url"
        value="jdbc:mysql://${db.host}:3306/${db.name}" />
    <property name="username" value="${db.user}" />
    <property name="password" value="${db.pass}" />     
</bean>

有很多选项关于属性文件可以存放在哪里的 Spring 类。您甚至可以进行替换并将它们作为环境变量传递:

    <bean id="myPropertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="searchSystemEnvironment" value="true" />
    <property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE" />
    <property name="locations">
        <list>
            <value>${database.configuration.file.url}</value>
        </list>
    </property>
</bean>

在 bash_profile (或其他)中:
export JAVA_OPTS="-Ddatabase.configuration.file.url=file:///etc/myapp/database.properties"

或者只是在调用“java”时传入相同的 -D 选项,具体取决于您在做什么。

FWIW,我们将属性文件单独维护为 RPM。

For all of our environments, configuration data lives on the target machines in the form of properties files. We use PropertyPlaceholderconfigurer from SpringFramework to bind these properties to our apps to keep things portable accross environments.

For example, as long as I know that /etc/myapp/database.properties will be present on whatever machine my app will be running on, then in my spring configuration, I just need something like so:

    <bean id="myPropertyConfigurer"
    class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="locations">
        <list>
            <value>/etc/myapp/database.properties</value>
        </list>
    </property>
</bean>
<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver" />
    <property name="url"
        value="jdbc:mysql://${db.host}:3306/${db.name}" />
    <property name="username" value="${db.user}" />
    <property name="password" value="${db.pass}" />     
</bean>

There are a bunch of options for that Spring class about where properties files can live. You can even make them substitutions and pass them in as environment variables:

    <bean id="myPropertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="searchSystemEnvironment" value="true" />
    <property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE" />
    <property name="locations">
        <list>
            <value>${database.configuration.file.url}</value>
        </list>
    </property>
</bean>

And in bash_profile (or whatever):
export JAVA_OPTS="-Ddatabase.configuration.file.url=file:///etc/myapp/database.properties"

Or just the same -D option passed in when you call "java" depending on what you are doing.

FWIW, we maintain our properties files separately as RPMs.

记忆で 2024-08-29 12:28:23

有很多不同的策略。所有这些都很好,取决于最适合您的。

  1. 构建单个工件并将配置部署到单独的位置。该工件可以具有占位符变量,并且在部署时可以读入配置。查看 Springs 属性占位符。它对于使用 Spring 并且不涉及操作的 Web 应用程序非常有效。
  2. 有一个位于 web 应用程序外部的外部化属性配置。保持位置不变并始终从属性配置中读取。在任何阶段更新配置,重新启动将采用新值。
  3. 如果您正在修改环境(即正在使用的应用程序服务器或用户/组权限),请考虑将上述方法与 puppet 或 Chef 一起使用。另请查看使用这些工具管理配置文件。

There are plenty of different strategies. All of them are good and depends on what suit you best.

  1. Build a single artifact and deploy configs to a separate location. The artifact could have placeholder variables and, on deployment, the config could be read in. Have a look at Springs property placeholder. It works fantastically for webapps that use Spring and doesn't involve getting ops involved.
  2. Have an externalised property config that lives outside of the webapp. Keep the location constant and always read from the property config. Update the config at any stage and a restart will be up the new values.
  3. If you are modifying the environment (i.e. application server being used or user/group permissions) look at using the above methods with puppet or chef. Also have a look at managing your config files with these tools.
迎风吟唱 2024-08-29 12:28:23

环境变量是最简单的方法。像其他任何时候一样设置它们,使用 System.getenv("...") 访问它们

Environment variables are just about the easiest way to go. Set them as you would any other time, access them w/ System.getenv("...")

Smile简单爱 2024-08-29 12:28:23

2023 年的现代解决方案:

最好的选择是创建 Spring Boot Java 应用程序,并在 application.propertiesapplication.yml< 中定义所有属性。 /代码> 文件。

优点:

  • 一个简单的文件,可以根据需要使用属性或 YAML 来管理所有内容。包括数据库内容、日志记录、服务器端口等。
  • 在代码中定义属性,这非常好。
  • 不再有混乱,因为您不再知道在哪里定义了什么。

Modern solution in 2023:

Your very best bet is to create Spring Boot Java application and define absolutely all of your properties in the application.properties or application.yml file.

Pros:

  • A simple file to manage everything using properties or YAML if you want. Including Database stuff, logging, server Port, etc.
  • Define your properties in your code, which is just excellent.
  • No more confusion because you do not know anymore where you defined what.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文