Как эмулировать поведение свойств java в конфигурации Typesafe (HOCON), где ключ определяется как «строка» и «объект» (с податрибутами)? - PullRequest
0 голосов
/ 10 января 2019

Я настраиваю стороннюю библиотеку, которая ожидает экземпляр java.util.Properties, и я хотел бы заполнить конфигурацию из моего (Typesafe / HOCON) файла application.conf.

Чтобы защитить невинных, я скажу, что свойства, которые ожидает моя сторонняя библиотека, равны

allowed.calories = 2000
allowed.calories.cheatday = 2200

где значение что-то наподобие «по умолчанию разрешено. Калории - 2000, тогда как для чит-дня применяются специальные правила, где система выделит вам до 2200 калорий ». Сторонняя библиотека требует, чтобы мы использовали эти свойства для конфигурации.

Когда мы читаем в application.conf с вышеуказанным содержимым с кодом ниже:

import com.typesafe.config.{Config, ConfigFactory}
import com.typesafe.scalalogging.StrictLogging

import scala.collection.JavaConverters._

object Main extends StrictLogging with App {
  ConfigFactory.load().entrySet().asScala.foreach { entry =>
    System.out.println("entry:" + entry);
  }
}

Мы видим вывод так:

entry:line.separator=Quoted("\n")
entry:user.country=Quoted("US")
    many more lines of stuff like the above...
...
entry:allowed.calories.cheatday=2200

Мы не видим никакой записи для ключа конфигурации 'позволен.калорий'

Проблема, с которой мы сталкиваемся при настройке HOCON, связана с представлением внутренней древовидной структуры Конфигурационные файлы, которые он использует.

Мы определяем allow.calories как «узел» конфигурации с числовым значением, но затем происходит переопределение allow.calories как объект с «субструктурой», то есть атрибутом с именем «cheatday». Это уничтожает предыдущее определение allow.calories ... которое не отображается в выводе.

Есть ли способ заставить конфигурацию Typesafe вести себя больше как карта свойств Java, чтобы мы могли иметь В нашей конфигурации присутствуют и allow.calories и allow.calories.cheatday?

...