Конфигурация Typesafe — исключение нулевого указателя

Я вручную создаю путь к классам для моего приложения Play/Scala/Akka, поэтому я могу использовать средство запуска ScalaTest для тестирования своего приложения на разных этапах конвейера CI без необходимости повторной компиляции. Однако я получаю следующую ошибку:

java.lang.NullPointerException:
  at com.typesafe.config.impl.Parseable$ParseableResources.rawParseValue(Parseable.java:509)
  at com.typesafe.config.impl.Parseable$ParseableResources.rawParseValue(Parseable.java:492)
  at com.typesafe.config.impl.Parseable.parseValue(Parseable.java:171)
  at com.typesafe.config.impl.Parseable.parseValue(Parseable.java:165)
  at com.typesafe.config.impl.Parseable.parse(Parseable.java:204)
  at com.typesafe.config.impl.ConfigImpl$1.call(ConfigImpl.java:368)
  at com.typesafe.config.impl.ConfigImpl$1.call(ConfigImpl.java:365)
  at com.typesafe.config.impl.ConfigImpl$LoaderCache.getOrElseUpdate(ConfigImpl.java:58)
  at com.typesafe.config.impl.ConfigImpl.computeCachedConfig(ConfigImpl.java:86)
  at com.typesafe.config.impl.ConfigImpl.defaultReference(ConfigImpl.java:365)

Вот команда, которую я запускаю:

/usr/lib/jvm/java-7-openjdk//bin/java -Xmx256M -Xms32M -Xbootclasspath/a:$BOOTCP -classpath '""' -Dscala.home=/usr/opt/scala -Dscala.usejavacp=true -jar /home/nick/repos/testrunnnertest/lib/scalatest.jar -R target/scala-2.10/test-classes -o 

Значение для $BOOTCP — это массивный список зависимостей, включая jar-файлы приложений, зависимости в .ivy2 и папки, содержащие файлы конфигурации (/conf, /test/resources). Я скопировал эту команду из сценария оболочки Scala. Я также использовал значение для $BOOTCP в качестве значения для -classpath, но у меня все еще была та же проблема.

Эта проблема возникает только тогда, когда я запускаю свои приемочные тесты, которые запускают тестовый сервер Play Framework. Таким образом, кажется вероятным, что это проблема с загрузкой основных конфигураций приложения в /conf, а не конфигураций /test/resources, которые загружаются, когда тесты модуля и интеграции успешно выполняются.


person user2668128    schedule 10.03.2014    source источник


Ответы (1)


Придя к этому вопросу довольно поздно, но вы когда-нибудь понять это? Какая версия конфигурации typesafe находится в вашем пути к классам?

Строка 509 на мастере выглядит не совсем правильной: https://github.com/typesafehub/config/blob/master/config/src/main/java/com/typesafe/config/impl/Parseable.java#L509

поэтому у вас может быть версия с немного другим источником.

Строка 509 версии 1.0.2 выглядит более вероятной: https://github.com/typesafehub/config/blob/v1.0.2/config/src/main/java/com/typesafe/config/impl/Parseable.java#L509

В этой строке, скорее всего, загрузчик классов нулевой, я думаю? Он должен исходить отсюда в этой трассировке: https://github.com/typesafehub/config/blob/v1.0.2/config/src/main/java/com/typesafe/config/impl/ConfigImpl.java#L365 Что, в свою очередь, происходит из: https://github.com/typesafehub/config/blob/v1.0.2/config/src/main/java/com/typesafe/config/ConfigFactory.java#L380

Итак, одна из теорий состоит в том, что поток не имеет установленного загрузчика класса контекста в случае, когда он выдает исключение. Я не могу сказать вам, почему это так в вашем сценарии, если это так, но, возможно, это зацепка.

Я не думаю, что конфигурация typesafe в любом случае должна вызывать NPE так «поздно», поэтому я создал https://github.com/typesafehub/config/issues/155, чтобы это исправить. Однако, скорее всего, в конечном итоге проблема в игре и/или в том, как вы настраиваете вещи, что загрузчик класса контекста потока имеет значение null, и никакой другой загрузчик класса не был предоставлен методам ConfigFactory.

Это предполагает, что NPE происходит от загрузчика нулевого класса, я не думаю, что это обязательно проблема, но это выглядит правдоподобно из этой трассировки стека.

person Havoc P    schedule 26.03.2014