2

Configあるオブジェクトを解決したい、たとえばconfig1、他のオブジェクトで解決したいconfig2.

この種のものを許可する唯一のパブリック API はconfig1.withFallback(config2).resolve(). ただし、これによりエントリが追加されますがconfig2、config1これは必要なものではありません。

ResolveContextいくつかの調査で、そのためのメソッドを提供するという名前の非公開クラスが見つかりました。そのため、リフレクションを使用してそれを利用しています。現在のコード:

object ConfigImplicits {
  implicit class RichConfig(val config: Config) extends AnyVal {
    def resolveWith(source: Config): Config = {
      val resolver = resolveContext.getDeclaredMethod(
        "resolve", 
        abstractConfigValue, 
        abstractConfigObject, 
        configResolveOptions
      )
      resolver.setAccessible(true)
      resolver.invoke(
        null,
        config.underlyingAbstractConfigObject,
        source.underlyingAbstractConfigObject,
        ConfigResolveOptions.defaults
      ).asInstanceOf[ConfigObject].toConfig
    }

    def underlyingAbstractConfigObject = {
      val f = simpleConfig.getDeclaredField("object")
      f.setAccessible(true)
      f.get(config)
    }
  }

  val resolveContext = Class forName "com.typesafe.config.impl.ResolveContext"
  val abstractConfigValue = Class forName "com.typesafe.config.impl.AbstractConfigValue"
  val abstractConfigObject = Class forName "com.typesafe.config.impl.AbstractConfigObject"
  val configResolveOptions = classOf[ConfigResolveOptions]
  val simpleConfig = Class forName "com.typesafe.config.impl.SimpleConfig"
}

非公開の内部に依存することは良い考えではないかもしれないことを認識しています. そう：

  1. どういうわけか見逃したが、すでにこれを行っているパブリックメソッドはありますか?
  2. そうでない場合は、プル リクエストを作成しますか?
4

1 に答える 1

1

私の知る限り、パブリック メソッドはありません。プライベート API に依存する代わりに、脆弱性の低い回避策として、最初にソース オブジェクトをフォールバックとして解決し、次に、解決したソース オブジェクトのキーを反復処理して、不要なキーをターゲット オブジェクトから削除することができます。

Config.resolveWith() を追加しない理由が思い浮かびませんが、考慮したことを覚えているので理由があったのだろうかと思います。誰も使わないだろうと思っただけかもしれません。

プル リクエストを行う場合は、必ずテストとドキュメントを含めてください。非常に小さなコードであることが判明したと仮定すると、プルリクエストは合理的だと思います (私が予想するように)。現在のマスター ブランチは、最終的な 1.2 リリースに登場する API の追加のために開かれています。

于 2013-06-25T14:36:45.953 に答える