Get java.lang.NoSuchMethodError: scala.collection.JavaConversions.asScalaIterable when calling the /topics/:topic endpoint

[AndrewSwerlick]

Whenever I call the topics/:topic endpoint I get the following error

java.lang.NoSuchMethodError: scala.collection.JavaConversions.asScalaIterable(Ljava/util/Collection;)Lscala/collection/Iterable;
    at io.confluent.kafkarest.MetadataObserver.getTopic(MetadataObserver.java:91)
    at io.confluent.kafkarest.resources.TopicsResource.getTopic(TopicsResource.java:70)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483) 
       .....(stack trace continues)

From some preliminary research it appear this could be due to differences between the compile time version of scala and the runtime.

http://stackoverflow.com/questions/4393946/nosuchmethoderror-when-attempting-to-implicitly-convert-a-java-to-scala-collecti

I'm running on Centos. Here's the output of java -version

java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)

I installed the package confluent-platform-2.11.5

[ewencp]

@AndrewSwerlick Thanks for the report. This is a bug in the wrapper script used to run the schema registry. To keep the non-Kafka packages simpler, we pin them to a specific Scala version and provide a copy of the jars with them. The wrapper script sets up the classpath to point at the necessary dependencies, but there was a leftover "kafka" entry that shouldn't have been there anymore.

You can see the one line fix in the referenced PR. The easiest solution for you is probably to just edit that script to remove the "kafka" entry. Alternatively, if you set CLASSPATH to include /usr/share/java/kafka-rest before invoking the script, it should use the version of the jar there instead of the one in /usr/share/java.

By the way, I went and checked our other projects, specifically schema-registry which uses a similar setup and the problem does not exist there.