You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's very likely that an exception can occur while trying to extract native libraries. In my case it was because the Karaf client had set the tmp dir to a non-standard location which wasn't readable, but this simple issue took a significant amount of time to track down, because the root exception or file location wasn't reported, only the message. Without the stacktrace, the (surprising) fact that a write was being attempted wasn't apparent either.
Here's the resulting, unhelpful, one liner I started with:
[vagrant@localhost data]$ /opt/karaf/bin/client
Logging in as karaf
391 [sshd-SshClient[4445629]-nio2-thread-2] WARN org.apache.sshd.client.keyverifier.AcceptAllServerKeyVerifier - Server at /0.0.0.0:8101 presented unverified RSA key: 49:03:6e:ad:91:7d:c2:11:cb:86:84:73:b2:9e:e9:4b
Could not load library. Reasons: [no jansi in java.library.path, Permission denied]
Here's the same error with the verbose flag, with the implication it's a read error, but no indication of where:
[vagrant@localhost java]$ /opt/karaf/bin/client -v
...
java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no jansi in java.library.path, Permission denied]
at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
at org.fusesource.jansi.internal.CLibrary.(CLibrary.java:42)
at org.fusesource.jansi.AnsiConsole.wrapOutputStream(AnsiConsole.java:48)
at org.fusesource.jansi.AnsiConsole.(AnsiConsole.java:38)
at org.apache.karaf.client.Main.main(Main.java:214)
My initial thought was a read permissions error, it wasn't until I read Library.java that I realised a write was being attempted, even then it took more time to determine the location was the standard tmp dir.
Besides not swallowing the original exception, when this sort of write IO fails, it would be best to report as much detail about the attempted operation as possible, ie the location that was attempted to be written to.
The text was updated successfully, but these errors were encountered:
The stack trace and any nested exception at https://github.com/fusesource/hawtjni/blob/master/hawtjni-runtime/src/main/java/org/fusesource/hawtjni/runtime/Library.java#L304 are discarded, whereas it should be chained to the resulting exception that is thrown, not just the message. In addition the location of the file operation that was attempted should be included.
It's very likely that an exception can occur while trying to extract native libraries. In my case it was because the Karaf client had set the tmp dir to a non-standard location which wasn't readable, but this simple issue took a significant amount of time to track down, because the root exception or file location wasn't reported, only the message. Without the stacktrace, the (surprising) fact that a write was being attempted wasn't apparent either.
Here's the resulting, unhelpful, one liner I started with:
Here's the same error with the verbose flag, with the implication it's a read error, but no indication of where:
My initial thought was a read permissions error, it wasn't until I read Library.java that I realised a write was being attempted, even then it took more time to determine the location was the standard tmp dir.
Besides not swallowing the original exception, when this sort of write IO fails, it would be best to report as much detail about the attempted operation as possible, ie the location that was attempted to be written to.
The text was updated successfully, but these errors were encountered: