błąd ClassNotFound gdy uruchomiony burza rozrusznik topologie w trybie lokalnym (Win10, OS X)

Question

Próbuję debugować Burza topologii (na burze v 1.0.0) pod Windows przez:

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); 

i uzyskać następujący błąd (WordCount/Wykrzyknik Stateful/lub innych topologii z burzy rozrusznika - nie ma znaczenia):

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] 

ten zachowuje się jak gdyby nie ma słoik plik w katalogu roboczym pracowników jest. Ale zgodnie z komentarzem ";, w trybie lokalnym nie ma słoika" w Nimbus.clj nie wydaje się być źle. W wersji 0.10.0 ten problem nie występuje. Jakieś pomysły?

Problem pojawia się przy próbie uruchomienia debugowania w IntelliJ używając maven-exec wtyczki z następującym wierszu poleceń w konfiguracji (jak zaleca here):

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

z katalogu, gdzie POM-file topologii jest położony.

UPD: problem jest zdecydowanie spowodowane niedostępnością dowolnej topologii lub burzy (rdzeniem) zajęcia dla wątku roboczego w trakcie jej inicjalizacji. (Zilustruje to zarówno topologie WordCount, jak i Exclamation). Odtworzenia z zakresem zależności "storm-core" i profilu intellij w POM-ach topologii nie dały nic.

Answer 1

Uruchomiłem mój LocalCluster z sbt run, jeśli uruchomię go przy użyciu java -jar fatjar.jar wszystko działa dobrze. Na razie zamierzam biec z Intellijem, wyszukując ścieżkę klas, nie wiem, dlaczego sbt zachowuje się dziwnie podczas rozwiązywania ścieżki klas. Każdy, kto ma jakieś informacje, prosimy o komentarz!

Answer 2

Znalazłem rozwiązanie: wykorzystanie standardowej funkcji budowania i działania Idea działa dobrze dla czystych topologii java. Ale tylko do wykonania uruchomi się kilka skryptów powłoki (jak splitsentece.py). Następnie kończy się niepowodzeniem z wyjątkiem pliku nie znaleziono, więc kompilacja bez maven nie wydaje się być w pełni funkcjonalna