读取dropwizard应用程序中的自定义配置文件时出错
因此，我们有一个普通的批处理应用程序，我们决定移植到dropwizard。我们希望使用dropwizard获得许多现成的好处，如运行状况检查、指标等。
稍后我们可能会添加一些REST管理endpoint，但现在我们只是使用DropWizard托管服务在单独的线程中启动应用程序。我们创建了一个示例配置yml文件，但它基本上只是一个框架。
这种移植主要是提升和移位，我们希望避免在代码中进行大量重构。该应用程序目前与两个不同的属性文件相关联，我们希望保持这种状态。
我们已经找到了一种方法来部署我们的应用程序，使用一个定制的部署器来生成这些属性文件“application.properties”和“system.properties ”,由于某种原因，应用程序无法读取这些文件，并抛出NPE。这是一个java应用程序。所有的jar都在lib目录下，配置文件在config目录下。它似乎不能解决那些文件。我试图搜索dropwizard文档，但没有找到任何有用的东西。代码只是希望文件在一个特定的目录中
private static final String APP_PROPERTIES_FILE = "/application.properties";
File file = new File(DataSourceFactory.class.getResource(filename)
.getFile());
投递版本： 1.2.2 这就是我运行应用程序的方式：
java -cp "deployed/App/lib/*:deployed/App/config/*" com.commercehub.app.MainClass server config.yml
任何意见都非常感谢！
共有1个答案
问题在于我的类路径。配置文件夹不需要尾随的/*。
java -cp "deployed/App/lib/*:deployed/App/config" com.commercehub.app.MainClass server config.yml
-
在我的dropwizard rest应用程序中，我的指标配置是这样的，(hello-world.yml) 这是一个SLF4J记者，我把它放在了我的YAML配置文件中。当我想获取这个值并在我的应用程序文件中使用它时。我看到的唯一选择是将此作为< code >地图阅读 此问题与graphite服务器配置的Dropwizard Yaml相同。但是这个问题还是没有答案，所以我创造了一个新问题来试试运气。
-
本文向大家介绍golang 使用 viper 读取自定义配置文件，包括了golang 使用 viper 读取自定义配置文件的使用技巧和注意事项，需要的朋友参考一下 viper 支持 Yaml、Json、 TOML、HCL 等格式，读取非常的方便。 viper 官网有案例:https://github.com/spf13/viper 创建 config.yaml 文件 建一个 config.go 用
-
我正在基于Dropwizard v0.9.1构建一个web堆栈。堆栈中的所有日志都通过AppenderFactory接口的自定义实现发送到Loggly: 此类未在我的应用程序类中的环境中注册。相反，它似乎是Dropwizard基于@JsonTypeName注释自动连接的。尽管如此，和字段由出现在我的配置yaml文件中的值填充： 问题是，这些配置值不会出现在应用程序的配置类中，这意味着在构建其他资源
-
我正在尝试为DropWizard Metrics创建一个自定义报告器，但找不到任何资源或示例来显示如何通过扩展来创建一个报告器。我可以通过遵循现有报告器（CSV、SLF4J等）来扩展这个类，但是我要在哪里注册它？ 以下是我试图注册的自定义记者的摘录: 而且，这是创建自定义报告程序的正确方法还是其他方法？ 先谢谢你。
-
我有一段扫描Spring上下文的代码： 我需要从文件，所以在类中，我有： （我从这里复制了YamlProperty tyLoaderFactory类） 是一个典型的Spring Boot文件，其中包含一些配置文件属性和默认配置文件： 在某些bean中，我使用读取属性。 当我运行我的应用程序，我传递变量，但我得到一个错误： 无法解析值“${file}”中的占位符“file” （由于applicati
-
问题内容： 好的，所以我不想在这里展开一场圣战，但是我们正在努力巩固处理应用程序配置文件的方式，我们正在努力决定采用哪种最佳方法。目前，我们分发的每个应用程序都在使用其自己的临时配置文件，无论是属性文件（ini样式），XML还是JSON（目前仅在内部使用！）。 目前，我们的大多数代码是Java，因此我们一直在研究Apache Commons Config ，但是我们发现它非常冗长。我们还研究了XM