jansi path

[Brad Wood]

Please see the details in this ticket:

https://ortussolutions.atlassian.net/browse/COMMANDBOX-729

I had to provide a workaround for some of my government users with really locked down PCs by overriding the temporary folder that JAnsi used in JLine2 for extracting a DLL file.  Can you confirm if this behavior still exists in JLine3 and if the same system property (library.jansi.path) would be needed to fix it?

Thanks!

~Brad

Developer Advocate

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

[Guillaume Nodet]

The extraction path is handled by the jansi library itself, so the same should apply to JLine3.

--
You received this message because you are subscribed to the Google Groups "jline-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jline-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brad Wood]

Ok, thanks.

[Brad Wood]

Hi, my US Gov users have started testing CommandBox 4/Jline3 and it seems what we discussed above is not correct.  In JLine2 they had to set a java system property of library.jansi.path because their PCs can't write to the appData folder.  In Jline3 this system prop isn't working any longer.  I had to figure out how to enable debugging, but once I did I saw this message:

FINE: Error creating JNA based terminal: C:\Users\user.name\AppData\Local\Temp\1\jna--337510509\jna1825582816334583471.dll: Access is denied

What is the correct way to overwrite the jansi path in Jline3?  

Thanks!

~Brad

[Brad Wood]

I forgot to include the stack trace of that error.  I also noticed this error references jna, not jansi.  I don't really understand the difference between the two, but perhaps there is another java system prop I need to override the temp folder used for JNA?

        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(Unknown Source)
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.load0(Unknown Source)
        at java.lang.System.load(Unknown Source)
        at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:906)
        at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:881)
        at com.sun.jna.Native.<clinit>(Native.java:156)
        at org.jline.terminal.impl.jna.win.Kernel32.<clinit>(Kernel32.java:22)
        at org.jline.terminal.impl.jna.win.JnaWinSysTerminal.<clinit>(JnaWinSysTerminal.java:25)
        at org.jline.terminal.impl.jna.JnaSupportImpl.winSysTerminal(JnaSupportImpl.java:26)
        at org.jline.terminal.TerminalBuilder.doBuild(TerminalBuilder.java:313)
        at org.jline.terminal.TerminalBuilder.build(TerminalBuilder.java:232)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at lucee.runtime.reflection.pairs.MethodInstance.invoke(MethodInstance.java:55)
        at lucee.runtime.reflection.Reflector.callMethod(Reflector.java:852)
        at lucee.runtime.util.VariableUtilImpl.callFunctionWithoutNamedValues(VariableUtilImpl.java:797)
        at lucee.runtime.PageContextImpl.getFunction(PageContextImpl.java:1718)
        at system.util.readerfactory_cfc$cf.udfCall(/commandbox/system/util/ReaderFactory.cfc:71)

[Brad Wood]

Actually, you know what-- there is more than one stack trace with references to both JNA and Jansi in there.  I just pasted the whole thing into a Gist so you can check it out.

https://gist.github.com/bdw429s/42d015efe8270c384ff4cb6ced8d1840

[Guillaume Nodet]

Well, as the error indicates, in this case, it's JNA, not JANSI.

You can disable JNA and it should use JANSI instead.

See the following property:

  https://github.com/jline/jline3/blob/master/terminal/src/main/java/org/jline/terminal/TerminalBuilder.java#L50

So try setting the above system property to false, and it will disable JNA, thus using JANSI instead (if it's in the classpath).

With the above, the library.jansi.path should work (see https://github.com/fusesource/hawtjni/blob/master/hawtjni-runtime/src/main/java/org/fusesource/hawtjni/runtime/Library.java#L24).

Guillaume

To unsubscribe from this group and stop receiving emails from it, send an email to jline-users+unsubscribe@googlegroups.com.

[Brad Wood]

So after tons of googling and reading code, I came to the conclusion that while this error was very similar to the jansi one, it was coming from another library (JNA).  I finally came upon this:

https://java-native-access.github.io/jna/4.2.1/com/sun/jna/Native.html#getTempDir--

And was able to override the tmp directory with this Java system property: jna.tmpdir

This seems to have gotten Jline3 running again on the crazy locked down govt issued computers that some of my users have to endure with no write access to the appData folder.

[Brad Wood]

Oops, I see we replied at the same time.  As you can see, there's no need to just turn off JNA.  I found a way to change the temp folder it writes to.

I don't know that your suggestion to force JANSI would work though.  If you examine the Gist I linked to above, you'll see that the JANSI loading also failed, but with a much less useful message.  The code for JANSI appears to check some major/minor version numbers and if those if statements aren't entered, it simply throws an empty exception.  So I'm not sure why the fallback to JANSI wasn't working, but JLine doesn't seem to really provide any information at run time regarding that.

Also, on a related note for someone who may come across this thread in the future, here is the code I used to programatically configure Jline's logging to dump out the console on startup which was how I got the information in the Gist.  Note, this code is CFML.  Adjust for your JVM lang flavor.  

// This will make the underlying JLine logger sing... 

var LevelClass = createObject( 'java', 'java.util.logging.Level');

var consoleHandler = createObject( 'java', 'java.util.logging.ConsoleHandler' );

consoleHandler.setLevel( LevelClass.FINEST );

consoleHandler.setFormatter( createObject( 'java', 'java.util.logging.SimpleFormatter' ) );

var jlineLogger = createObject( 'java', 'java.util.logging.Logger').getLogger("org.jline");

jlineLogger.setLevel( LevelClass.FINEST );

jlineLogger.addHandler( consoleHandler );

// And this will make the JNA lib chirp

systemSettings.setSystemProperty( 'jna.debug_load', true );

Thanks!

~Brad