ClassNotFound Fehler bei der Ausführung von Sturm-Starter-Topologien im lokalen Modus (Win10, OS X)

Question

Ich versuche Sturm Topologie zu debuggen (Storm v 1.0.0) unter Windows über:

TopologyBuilder builder = new TopologyBuilder(); 
builder.setSpout("spout", new RandomIntegerSpout()); 
builder.setBolt("partialsum", new StatefulSumBolt("partial"), 1).shuffleGrouping("spout"); 
builder.setBolt("printer", new PrinterBolt(), 2).shuffleGrouping("partialsum"); 
builder.setBolt("total", new StatefulSumBolt("total"), 1).shuffleGrouping("printer"); 

Config conf = new Config(); 
conf.setDebug(false); 
LocalCluster cluster = new LocalCluster(); 
StormTopology topology = builder.createTopology(); 
cluster.submitTopology("test", conf, topology); 

und nutzen Sie die folgende Fehler (Wordcount/Exclamation/Stateful oder andere Topologien von Sturm-Starter - egal):

java.lang.RuntimeException: java.lang.ClassNotFoundException: org.apache.storm.daemon.acker 
at org.apache.storm.utils.Utils.javaDeserialize(Utils.java:181) ~[storm-core-1.0.0.jar:1.0.0] 
at org.apache.storm.utils.Utils.getSetComponentObject(Utils.java:430) ~[storm-core-1.0.0.jar:1.0.0] 
at org.apache.storm.daemon.task$get_task_object.invoke(task.clj:74) ~[storm-core-1.0.0.jar:1.0.0] 
at org.apache.storm.daemon.task$mk_task_data$fn__66.invoke(task.clj:177) ~[storm-core-1.0.0.jar:1.0.0] 
at org.apache.storm.util$assoc_apply_self.invoke(util.clj:930) ~[storm-core-1.0.0.jar:1.0.0] 
at org.apache.storm.daemon.task$mk_task_data.invoke(task.clj:170) ~[storm-core-1.0.0.jar:1.0.0] 
at org.apache.storm.daemon.task$mk_task.invoke(task.clj:181) ~[storm-core-1.0.0.jar:1.0.0] 
at org.apache.storm.daemon.executor$mk_executor$fn__6149.invoke(executor.clj:371) ~[storm-core-1.0.0.jar:1.0.0] 
at clojure.core$map$fn__4553.invoke(core.clj:2622) ~[clojure-1.7.0.jar:?] 
at clojure.lang.LazySeq.sval(LazySeq.java:40) ~[clojure-1.7.0.jar:?] 
at clojure.lang.LazySeq.seq(LazySeq.java:49) ~[clojure-1.7.0.jar:?] 
at clojure.lang.RT.seq(RT.java:507) ~[clojure-1.7.0.jar:?] 
at clojure.core$seq__4128.invoke(core.clj:137) ~[clojure-1.7.0.jar:?] 
at clojure.core.protocols$seq_reduce.invoke(protocols.clj:30) ~[clojure-1.7.0.jar:?] 
at clojure.core.protocols$fn__6506.invoke(protocols.clj:101) ~[clojure-1.7.0.jar:?] 
at clojure.core.protocols$fn__6452$G__6447__6465.invoke(protocols.clj:13) ~[clojure-1.7.0.jar:?] 
at clojure.core$reduce.invoke(core.clj:6519) ~[clojure-1.7.0.jar:?] 
at clojure.core$into.invoke(core.clj:6600) ~[clojure-1.7.0.jar:?] 
at org.apache.storm.daemon.executor$mk_executor.invoke(executor.clj:372) ~[storm-core-1.0.0.jar:1.0.0] 
at org.apache.storm.daemon.worker$fn__6779$exec_fn__3235__auto__$reify__6781$iter__6786__6790$fn__6791.invoke(worker.clj:634) ~[storm-core-1.0.0.jar:1.0.0] 
at clojure.lang.LazySeq.sval(LazySeq.java:40) ~[clojure-1.7.0.jar:?] 
at clojure.lang.LazySeq.seq(LazySeq.java:49) ~[clojure-1.7.0.jar:?] 
at clojure.lang.RT.seq(RT.java:507) ~[clojure-1.7.0.jar:?] 
at clojure.core$seq__4128.invoke(core.clj:137) ~[clojure-1.7.0.jar:?] 
at clojure.core$dorun.invoke(core.clj:3009) ~[clojure-1.7.0.jar:?] 
at clojure.core$doall.invoke(core.clj:3025) ~[clojure-1.7.0.jar:?] 
at org.apache.storm.daemon.worker$fn__6779$exec_fn__3235__auto__$reify__6781.run(worker.clj:634) ~[storm-core-1.0.0.jar:1.0.0] 
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_65] 
at javax.security.auth.Subject.doAs(Subject.java:422) ~[?:1.8.0_65] 
at org.apache.storm.daemon.worker$fn__6779$exec_fn__3235__auto____6780.invoke(worker.clj:606) ~[storm-core-1.0.0.jar:1.0.0] 
at clojure.lang.AFn.applyToHelper(AFn.java:178) ~[clojure-1.7.0.jar:?] 
at clojure.lang.AFn.applyTo(AFn.java:144) ~[clojure-1.7.0.jar:?] 
at clojure.core$apply.invoke(core.clj:630) ~[clojure-1.7.0.jar:?] 
at org.apache.storm.daemon.worker$fn__6779$mk_worker__6874.doInvoke(worker.clj:580) [storm-core-1.0.0.jar:1.0.0] 
at clojure.lang.RestFn.invoke(RestFn.java:512) [clojure-1.7.0.jar:?] 
at org.apache.storm.daemon.supervisor$fn__7647.invoke(supervisor.clj:1200) [storm-core-1.0.0.jar:1.0.0] 
at clojure.lang.MultiFn.invoke(MultiFn.java:251) [clojure-1.7.0.jar:?] 
at org.apache.storm.daemon.supervisor$get_valid_new_worker_ids$iter__7208__7212$fn__7213.invoke(supervisor.clj:380) [storm-core-1.0.0.jar:1.0.0] 
at clojure.lang.LazySeq.sval(LazySeq.java:40) [clojure-1.7.0.jar:?] 
at clojure.lang.LazySeq.seq(LazySeq.java:49) [clojure-1.7.0.jar:?] 
at clojure.lang.RT.seq(RT.java:507) [clojure-1.7.0.jar:?] 
at clojure.core$seq__4128.invoke(core.clj:137) [clojure-1.7.0.jar:?] 
at clojure.core$dorun.invoke(core.clj:3009) [clojure-1.7.0.jar:?] 
at clojure.core$doall.invoke(core.clj:3025) [clojure-1.7.0.jar:?] 
at org.apache.storm.daemon.supervisor$get_valid_new_worker_ids.invoke(supervisor.clj:367) [storm-core-1.0.0.jar:1.0.0] 
at org.apache.storm.daemon.supervisor$sync_processes.invoke(supervisor.clj:428) [storm-core-1.0.0.jar:1.0.0] 
at clojure.core$partial$fn__4527.invoke(core.clj:2492) [clojure-1.7.0.jar:?] 
at org.apache.storm.event$event_manager$fn__909.invoke(event.clj:40) [storm-core-1.0.0.jar:1.0.0] 
at clojure.lang.AFn.run(AFn.java:22) [clojure-1.7.0.jar:?] 
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_65] 

Dies verhält sich wie wenn es keine jar-Datei in Arbeiter Arbeitsverzeichnis ist. Aber laut Kommentar ";; im lokalen Modus gibt es kein Glas" in Nimbus.clj scheint es nicht falsch zu sein. In Version 0.10.0 tritt dieses Problem nicht auf. Irgendwelche Ideen?

Das Problem tritt auf, wenn ich versuche, eine Debug in IntelliJ mit Maven-Exec-Plugin mit der folgenden Befehlszeile in der Konfiguration zu laufen (wie here empfohlen):

compile exec:java -Dstorm.topology=org.apache.storm.starter.WordCountTopology 

aus dem Verzeichnis, in der POM-Datei der Topologie gelegen.

UPD: Das Problem wird definitiv durch die Nichtverfügbarkeit von Klassen (Topologie oder Storm-Core) für Worker-Thread während der Initialisierung verursacht. (Der Versuch, WordCount- und Exclamation-Topologien zu verwenden, veranschaulicht dies). Das Spiel mit dem Umfang der "Storm-Core" -Abhängigkeit und dem Intellij-Profil in den Topologie-POM-s gab nichts.

Answer 1

Ich habe meine LocalCluster mit sbt run ausgeführt, wenn ich es mit java -jar fatjar.jar läuft alles läuft gut. Im Moment werde ich mit Intellij laufen und den Klassenpfad aussortieren, keine Ahnung, warum sich sbt merkwürdig verhält, wenn der Klassenpfad aufgelöst wird. Jeder mit irgendwelchen Informationen bitte kommentieren!

Answer 2

Ich habe eine Lösung gefunden: Die Verwendung von Standard Ideas Aufbau- und Ablauffunktionen funktioniert gut für klare Java-Topologien. Aber nur bis zur Ausführung werden einige Shell-Skripte (wie zB splsentece.py) ausgeführt. Dann schlägt es mit Ausnahme der Datei nicht gefunden fehl, also scheint die Kompilierung ohne Maven nicht voll funktionsfähig zu sein