https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-1591 controller <p>Some downstream distributions (I know of at least one..) object to having native <b>.so binaries bundled in Java JAR, such as the /META-INF/native/</b>/*/libleveldbjni.so in leveldbjni-all-1.8-odl.jar, and would prefer to be able to use a LevelDB native binary installed by OS package manager (e.g. RPM).</p> <p>The as-is way is convenient though as default, so this should be more like an option: e.g. a -D or a sep. Karaf feature or even just a fall-back built into leveldbjni - like if no suitable /META-INF/native/<b>/</b>/libleveldbjni.so found, then attempt to find and use a LevelDB native binary installed by OS package manager.</p> <p>Operating System: All<br/> Platform: All</p> CONTROLLER-1591

Make it possible to use LevelDB native binary installed by OS package manager, instead of the one bundled in leveldbjni-all

Bug Resolved Cannot Reproduce Unassigned Michael Vorburger Mon, 6 Feb 2017 16:54:21 +0000 Tue, 25 Jul 2023 08:24:21 +0000 Tue, 28 Feb 2017 11:28:01 +0000 clustering 0 0 <p>I dug a little bit more into this today, and believe this would probably require a little bit of work upstream in leveldbjni, but not much - I can now see what would have to be done where how; here are some pointers, for another day:</p> <p>Background: ODL uses <a href="http://doc.akka.io/docs/akka/current/scala/persistence.html" class="external-link" target="_blank" rel="nofollow noopener">http://doc.akka.io/docs/akka/current/scala/persistence.html</a>, which uses <a href="https://github.com/fusesource/leveldbjni/" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/fusesource/leveldbjni/</a>, which is "just" a Java wrapper (based on <a href="http://fusesource.github.io/hawtjni/" class="external-link" target="_blank" rel="nofollow noopener">http://fusesource.github.io/hawtjni/</a>) for <a href="https://github.com/google/leveldb" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/google/leveldb</a> ...</p> <p>Next step: <a href="https://github.com/fusesource/leveldbjni/issues/90" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/fusesource/leveldbjni/issues/90</a> ?</p> <p>The point of this issue actually is less the "binary installed by OS package manager" part than the "an alternative to those bundled inside the leveldbjni-all JAR" ...</p> <p>Basically I think we need to be able to be more flexible re. how the LevelDB binaries are searched for, found, and loaded, and have ODL pick it up from the system... This would also help with issues such as <a href="https://jira.opendaylight.org/browse/CONTROLLER-1389" title="Leveldbjni not available on ARM" class="issue-link" data-issue-key="CONTROLLER-1389"><del>CONTROLLER-1389</del></a> so for e.g. for ARM, you should be able to build/fix LevelDB, not leveldbjni which is just the wrapper, yourself, without having to touch ODL.</p> <p>Looking at <a href="https://github.com/fusesource/hawtjni/blob/master/hawtjni-runtime/src/main/java/org/fusesource/hawtjni/runtime/Library.java" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/fusesource/hawtjni/blob/master/hawtjni-runtime/src/main/java/org/fusesource/hawtjni/runtime/Library.java</a>, which I've now found is what underlies this, it may actually already be possible to do this using system properties like -Dlibrary.leveldbjni.path=... (and perhaps -Dlibrary.leveldbjni.version=..), somehow (in a quick test, I wasn't able to get this working; e.g. -Dlibrary.leveldbjni.path=/lib64/libleveldb.so.1 does not work, because it then actually looks for /lib64/libleveldb.so.1/libleveldbjni.so ...)</p> <p><a href="https://bugzilla.redhat.com/show_bug.cgi?id=1420383" class="external-link" target="_blank" rel="nofollow noopener">https://bugzilla.redhat.com/show_bug.cgi?id=1420383</a></p> <p><a href="https://bugzilla.redhat.com/show_bug.cgi?id=1420433" class="external-link" target="_blank" rel="nofollow noopener">https://bugzilla.redhat.com/show_bug.cgi?id=1420433</a></p> <p>Closing this, because as detailed in <a href="https://github.com/fusesource//issues/90:" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/fusesource//issues/90:</a></p> <p>(a) it turns out that IFF a libleveldbjni.so is available somewhere on the FS (outside of the JAR where it's embedded default), then leveldbjni Java code can already be made to use it via an e.g. -Dlibrary.leveldbjni.path=/tmp/ - I had tested that (using a leveldbjni unit tests, not ODL/Karaf, but I see no reason why this wouldn't work for ODL via a Karaf startup -D as well).</p> <p>(b) getting a new official RPM placing libleveldbjni.so into e.g. /lib64/ seems to be a bigger PITA than anticipated, due to the <a href="https://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI" class="external-link" target="_blank" rel="nofollow noopener">https://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI</a> policy.</p> Blocks CONTROLLER-1389 Development External issue ID 7742 External issue URL Rank 0|i02rin: