我有一个由约。 20个java组件。 大约一半的组件是服务器，另外一半是批处理程序。 几乎所有这些都直接与oracle数据库（通过我们的一些基础设施代码jar进行jdbc）对话，另外几个组件与一些与数据库通信的服务器进行通信。 无论如何，每个组件都配置了许多XML配置文件。 这些几乎不可能维持。 某些配置特定于其他类似的组件（数据库URL，连接器等）
更糟糕的是，应用程序未安装在许多环境中 - 实际上只有大约10个环境（qa，dev，生产等）。 但拥有这些环境的人似乎无法正确维护配置。 特别是每当有升级时，总会出现配置错误。 我甚至开始将一些环境配置检查到SVN以及代码。 我曾经尝试过一个xml架构验证器（它包括在.xsd文件中定义有效的XML，如果架构规则被破坏但是没有用，则抛出错误）
我认为我遗漏了一些基本的东西 - 也许有一个工具来管理这个或者我应该将配置存储在数据库中。 该应用程序主要是由同事设计的，但我觉得它过于可配置 - 事实上，许多配置实际上是指类 - 即可以选择处理程序和解析器等 - XML配置几乎看起来像代码。 任何建议都非常感谢 彼得
答案 0 :(得分：1)
用XML代替代码通常是一个坏主意;声明性的东西可能没问题，但程序性的东西可能不是。
如果所有配置都是在Java代码中定义的，那么很多升级问题都会变成编译问题。编译器会为你挑选它们，你可以纠正它们。
所以你有一个多部分的问题。您需要将配置信息合理化为一组分区（每个组件，每个安装，全局）。您需要尽可能在编译时尝试验证配置信息。并且您需要为加载的配置编写验证，以便对其进行完整性检查。
尽可能将配置相对静态的东西转移到Guice（至少，这是我更喜欢的）。许多事情以一种不错的，类型安全的方式发生。
考虑为应用的每个实例运行WebDAV服务器，并将配置存储到其中。每个人都可以点击一个简单的URL来拉取当前版本的配置文件。
或者，使用其REST功能建立一个像BaseX这样的轻量级XML数据库，然后在那里存储和加载配置信息。使用JSLP或类似的东西让您的组件找到中央配置存储库。
使用XML DB的另一个好处是，您可以通过查询所有配置文件集来进行大量的健全性检查和更新。例如，如果应用程序的给定实例在每个配置文件中应该具有相同的JDBC参数，则简单的xquery将告诉您这是否为真。
如果您无法修改拉动配置文件的应用程序（配置文件格式已修复），请考虑为汇编的XML数据库编写查询servlet嵌套块或模板中所需的配置信息。这将使您能够找出配置文件之间的共同点，并动态生成这些块的参数化版本。
听起来这里的关键是进行渐进式改进。允许使用旧方法进行配置，但首先要为中央配置源配置外观。
答案 1 :(得分：1)
我认为配置文件的语法不是问题的核心：使用Java属性文件而不是XML会让您遇到完全相同的问题。可能存在配置信息过于分散的问题 - 很难说清楚。主要问题似乎是整个事情太脆弱了 - 应用程序太依赖于手动配置，并且似乎每个环境的配置需要不同。您应该尝试专注于减少需要设置的配置参数的数量，以使系统正常工作（不必减少可用于诊断的选项等，以便在真正需要时使用。），具有智能默认值和自我配置。甚至可能投资创建安装向导。
答案 2 :(得分：0)
由于您有一些Oracle数据库，为什么不将配置存储在那里？
然后，您只需要一个或两个配置参数即可指向适合该环境的Oracle数据库，并从数据库下载其余配置。
对于任何给定的环境，配置表的内容应该是非常静态的，因此当您将软件迁移到其生命周期时，除了jdbc连接之外，不需要修改任何内容。