CODEWITHSUNDEEP
javascalaplayframeworkscalatesttypesafe-config
user2668128
user2668128

Reputation: 42302

Typesafe config - Null Pointer Exception

I am manually constructing the classpath for my Play/Scala/Akka application so I can use the ScalaTest runner to test my application during different stages of a CI pipeline without the need to recompile. However, I get the following error:

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)

Here is the command I am running:

/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

The value for $BOOTCP is a massive list of dependencies including the application jars, the dependencies in .ivy2 and the folders containing the config files (/conf, /test/resources). I copied this command from the Scala shell script. I also used the value for $BOOTCP as the value for -classpath, but I still had the same problem.

This problem only happens when I run my acceptance tests which are spinning up a Play Framework Test Server. So it seems likely that it is a problem loading the main application configs in /conf rather than the /test/resources configs which appear to load find when the Unit and Integration tests happily run.

Upvotes: 1

Views: 1518

Answers (1)

Havoc P
Havoc P

Reputation: 8467

Coming to this question pretty late, but did you ever figure it out? Which typesafe config version is on your classpath?

Line 509 on master doesn't look like it could be quite the right line: https://github.com/typesafehub/config/blob/master/config/src/main/java/com/typesafe/config/impl/Parseable.java#L509

so you may have a version with slightly different source.

Version 1.0.2 line 509 looks maybe more likely: https://github.com/typesafehub/config/blob/v1.0.2/config/src/main/java/com/typesafe/config/impl/Parseable.java#L509

On that line most likely the class loader is null I guess? It's supposed to come from here in that trace: https://github.com/typesafehub/config/blob/v1.0.2/config/src/main/java/com/typesafe/config/impl/ConfigImpl.java#L365 Which in turn comes from: https://github.com/typesafehub/config/blob/v1.0.2/config/src/main/java/com/typesafe/config/ConfigFactory.java#L380

So one theory is that the thread has no context class loader set in the case where it throws an exception. I can't tell you why that's the case in your scenario, if it is, but perhaps it is a lead.

I don't think typesafe config should throw NPE this "late" in any case so I created https://github.com/typesafehub/config/issues/155 to fix this up. However it most likely is ultimately a problem in play and/or how you're setting things up that the thread context class loader is null and no other class loader was provided to ConfigFactory methods.

This is assuming that the NPE is from a null class loader, I don't think that's necessarily the problem, but it looks plausible from that stack trace.

Upvotes: 1

Related Questions