ctubbsii commented on a change in pull request #2414:
URL: https://github.com/apache/accumulo/pull/2414#discussion_r789635333
##########
File path:
minicluster/src/main/java/org/apache/accumulo/miniclusterImpl/MiniAccumuloClusterImpl.java
##########
@@ -327,6 +334,13 @@ public MiniAccumuloClusterImpl(MiniAccumuloConfigImpl
config) throws IOException
this.config = config.initialize();
+ if (Boolean.TRUE.equals(Boolean
+
.valueOf(this.config.getSiteConfig().get(Property.TSERV_NATIVEMAP_ENABLED.name()))))
{
+ if (!NativeMap.isLoaded())
+ throw new RuntimeException(
+ "MAC configured to use native maps, but unable to load the
library.");
+ }
+
Review comment:
tl;dr there's good reasons behind it, but it's complicated.
Messing with `LD_LIBRARY_PATH` isn't good practice. Ideally, the native
library is installed by a package manager into `/usr/lib{64}/whatever` and can
be loaded without messing with environment variables. If this is the case, then
it should just be picked up automatically by `System.loadLibrary("accumulo")`.
Messing with `LD_LIBRARY_PATH` directly is just a hack to get
`System.loadLibrary()` to find it from a standalone "tarball" packaging.
However, `System.loadLibrary()` isn't always recommended. In some systems,
the file naming conventions won't match up to the name of the files. For
example, on Macs, it can be a problem if the filename is `libaccumulo.jnilib`
instead of `libaccumulo.dylib` or vice-versa. In those cases, it's not enough
to specify the path. You have to specify the exact file. This is also the way
it is supposed to be done for all JNI libs according to the Fedora/EPEL/RHEL
packaging guidelines for Java. In such cases, you have to have some mechanism
to specify the files directly, so you can use `System.load(filename)` instead
of `System.loadLibrary(libname)`. Hence the property. We can inject specific
filenames (but we also allow directories that we'll search) using the value of
the Java system property `accumulo.native.lib.path`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
