2013-07-19 16 views
6

Sto scrivendo una semplice app in Scala che utilizza un database leveldb tramite la libreria leveldbjni. Il mio file build.sbt si presenta così:Libreria Scala SBT e JNI

name := "Whatever" 

version := "1.0" 

scalaVersion := "2.10.2" 

libraryDependencies ++= Seq(
    "org.iq80.leveldb" % "leveldb-api" % "0.6", 
    "org.fusesource.leveldbjni" % "leveldbjni-all" % "1.7" 
) 

Un Object è quindi responsabile per la creazione di un database. Sfortunatamente se eseguo il programma torno a java.lang.UnsatisfiedLinkError, generato dalla libreria hawtjni che gli exploit leveldbjni sono sotto il cofano.

L'errore può essere attivato facilmente anche dalla console Scala:

scala> import java.io.File 
scala> import org.iq80.leveldb._ 
scala> import org.fusesource.leveldbjni.JniDBFactory._ 
scala> factory.open(new File("test"), new Options().createIfMissing(true)) 

java.lang.UnsatisfiedLinkError: org.fusesource.leveldbjni.internal.NativeOptions.init()V 
    at org.fusesource.leveldbjni.internal.NativeOptions.init(Native Method) 
    at org.fusesource.leveldbjni.internal.NativeOptions.<clinit>(NativeOptions.java:54) 
    at org.fusesource.leveldbjni.JniDBFactory$OptionsResourceHolder.init(JniDBFactory.java:98) 
    at org.fusesource.leveldbjni.JniDBFactory.open(JniDBFactory.java:167) 
    at .<init>(<console>:15) 
... 
scala> System getProperty "java.io.tmpdir" 
res2: String = /var/folders/1l/wj6yg_wd15sg_gcql001wchm0000gn/T/ 

non riesco a capire cosa sta succedendo da quando la biblioteca è sempre correttamente estratto dal file jar, ma non è sempre caricato per alcune ragioni.

$ file /var/folders/1l/wj6yg_wd15sg_gcql001wchm0000gn/T/lib* 
/var/folders/1l/wj6yg_wd15sg_gcql001wchm0000gn/T/libleveldbjni-1.7.jnilib: Mach-O universal binary with 2 architectures 
/var/folders/1l/wj6yg_wd15sg_gcql001wchm0000gn/T/libleveldbjni-1.7.jnilib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 
/var/folders/1l/wj6yg_wd15sg_gcql001wchm0000gn/T/libleveldbjni-1.7.jnilib (for architecture i386): Mach-O dynamically linked shared library i386 

Credo che il problema è probabilmente legato al programma di caricamento classe che impiega SBT, ma io non sono sicuro perché io sono relativamente nuovo a Scala.

UPDATE

Ancora non ha trovato che cosa o chi è il colpevole. In ogni caso la libreria è effettivamente trovato e caricato correttamente, dato che posso eseguire i seguenti comandi:

scalac> import org.fusesource.leveldbjni.internal.NativeDB 
scalac> NativeDB.LIBRARY.load() 

L'errore è in qualche modo a causa della funzione init() che secondo la hawtjnidocumentation è responsabile dell'impostazione tutti i campi statici annotati come campi costanti con il valore costante. L'eccezione può ancora essere attivato digitando:

scalac> import org.fusesource.leveldbjni.internal.NativeOptions 
scalac> new NativeOptions() 
java.lang.UnsatisfiedLinkError: org.fusesource.leveldbjni.internal.NativeOptions.init()V 
    at org.fusesource.leveldbjni.internal.NativeOptions.init(Native Method) 
    at org.fusesource.leveldbjni.internal.NativeOptions.<clinit>(NativeOptions.java:54) 
    at .<init>(<console>:9) 
+0

Qual è il contenuto della proprietà di sistema 'java.library.path'? Hai provato a impostare questa proprietà sul percorso in cui si trovano le librerie estratte? – Beryllium

+0

Sì già provato utilizzando tutte le opzioni di configurazione possibili. Ancora lo stesso errore – nopper

+0

Quali versioni di OS/JDK stai usando? –

risposta

2

A quanto pare questo è un problema noto come documentato in questo sbt issue page. Ho implementato, in base allo eventsourced documentation, un comando personalizzato run-nobootcp che esegue il codice senza aggiungere la libreria Scala al percorso di classe di avvio.

Questo dovrebbe risolvere il problema.

+0

Su OS X 10.8 con sbt 0.13 e scala 2.10 tramite MacPorts, ottengo il problema originariamente descritto. SBT numero # 358 indica che questo problema dovrebbe essere risolto con sbt 0.13, ma non sembra essere il caso. Anche il comando run-nobootcp personalizzato non funziona ... ma sto solo copiando e incollando senza una reale comprensione. È interessante notare che l'utilizzo di leveldbjni all'interno di un progetto Play funziona alla grande. –

+0

Attualmente sto usando scala 2.10 e sbt 0.13 su OSX 10.8.5 senza problemi ora, usando un task 'run-nobootcp'. Sei sicuro di seguire correttamente le istruzioni? – nopper

+0

Non sono affatto sicuro, no, essendo un noob Scala. leveldbjni _does_ funziona bene all'interno di un contesto di app Play, però, quindi è abbastanza buono per il momento. –