VMware Cloud Community
aenagy
Hot Shot
Hot Shot

java.lang.NoClassDefFoundError: Could not initialize class org.fusesource.jansi.internal.Kernel32 (CloudClient 4.5.0)

When running CloudClient I encounter the following error:

java.lang.NoClassDefFoundError: Could not initialize class org.fusesource.jansi.internal.Kernel32

        at org.fusesource.jansi.internal.WindowsSupport.getConsoleMode(WindowsSupport.java:50)

        at jline.WindowsTerminal.getConsoleMode(WindowsTerminal.java:204)

        at jline.WindowsTerminal.init(WindowsTerminal.java:82)

        at jline.TerminalFactory.create(TerminalFactory.java:101)

        at jline.TerminalFactory.get(TerminalFactory.java:158)

        at jline.console.ConsoleReader.<init>(ConsoleReader.java:229)

        at jline.console.ConsoleReader.<init>(ConsoleReader.java:221)

        at jline.console.ConsoleReader.<init>(ConsoleReader.java:209)

        at com.vmware.cloudclient.core.authentication.SSLCertificateService.checkAndAddSSLCertificate(SSLCertificateService.java:194)

        at com.vmware.cloudclient.core.authentication.CafeSSOAuthentication.Login(CafeSSOAuthentication.java:67)

        at com.vmware.cloudclient.core.authentication.CafeSSOAuthentication.ReadSessionOrPropertiesAndLogin(CafeSSOAuthentication.java:608)

        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 org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:366)

        at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:311)

        at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:134)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:409)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1620)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:555)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)

        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)

        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)

        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)

        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)

        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:519)

        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:508)

        at org.springframework.context.support.AbstractApplicationContext.getBeansOfType(AbstractApplicationContext.java:1188)

        at org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors(BeanFactoryUtils.java:261)

        at org.springframework.shell.core.JLineShellComponent.afterPropertiesSet(JLineShellComponent.java:100)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1687)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1624)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:555)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)

        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)

        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)

        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)

        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)

        at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:761)

        at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:867)

        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:543)

        at com.vmware.cloudclient.startup.CloudClientBootstrap.<init>(CloudClientBootstrap.java:114)

        at com.vmware.cloudclient.startup.CloudClientBootstrap.<init>(CloudClientBootstrap.java:87)

        at com.vmware.cloudclient.startup.CloudClientBootstrap.main(CloudClientBootstrap.java:70)

        at com.vmware.cloudclient.startup.CloudClient.main(CloudClient.java:233)

I found a suggestion to install/update Microsoft C++ runtime 32-bit (https://bukkit.org/threads/could-not-initialize-class-org-fusesource-jansi-internal-kernel32.86345/ ) -- done.

I also looked for '*jansi*.*' and '*fuse*.*' in the CloudClient lib founder but there were no matches.

Another suggestion was to ensure that Java had access to a Jansi DLL (MuleSoft Support Center ) -- I'm pretty sure I didn't have this installed on any other machine running CloudClient.

Any suggestions?

Reply
0 Kudos
3 Replies
eoinbyrne
Expert
Expert

Just downloaded 4.5 there and there are jansi Native libraries shipped in the jline-2.12 JAR contained in the pack.... There must be a class or definition somewhere which selects and loads the right DLL (or .so) depending on OS checks etc.

pastedImage_0.png

There's also a note on the JANSI site about Windows XP user needing the MS C++ Runtime SP1 for Jansi support but you should have that covered

What version of Windows are you using? Also, are you running cloudclient.bat from within a Command prompt or double-clicking on the batch file in explorer? Sometimes the explorer approach can produce a different runtime context that from a Command prompt window + when using the latter you can use "set" commands to either change environment variables or at least print them. Explorer will launch with everything defaulted to the System settings + your Profile settings.

I've split open the JARs and used a decompiler tool to inspect the code - looks like CloudClient tries to do the following

1. Detect OS type and bit version

2. Extract the required native support library (DLL or .so) to wherever "java.io.tmpdir" points to

3. Load the library

Your stacktrace there shows a NoClassDefFound error which might mean the extraction failed?

In this case, you could verify that the user you're running cloudclient.bat as can write to whatever directory %TEMP% (or %TMP% on some versions of Windows) points to

-- OR --

Alternatively, edit cloudclient.bat and add this extra System var to the Java exec call

-Djava.io.tmpdir=c:\<some-dir-you-can-definitely-write-to>

e.g.,

%JAVACMD% %JAVA_OPTS% -Djava.io.tmpdir=c:\myfaketempdir -Djava.awt.headless=true -Djsse.enableSNIExtension=false -Dlog4j.configurationFile=file://"%BASEDIR%"/log4j2.xml -classpath %CLASSPATH% -Dapp.name="cloudclient" -Dapp.repo="%REPO%" -Dapp.home="%BASEDIR%" -Dbasedir="%BASEDIR%" com.vmware.cloudclient.startup.CloudClient %CMD_LINE_ARGS%

Anyway, hope you get sorted

Reply
0 Kudos
aenagy
Hot Shot
Hot Shot

eoinbyrne​:

Hmmm. Interesting.

It might help to back up a bit with some history and context. I had copied the entire contents of the CloudClient 4.5 folder (D:\CloudClient) from another computer (Windows Server 2012 R2) to the same location (D:\CloudClient) to a destination computer (Windows Server 2008 R2 with SP 1), launched PowerShell then ran:

push-location -path D:\CloudClient

D:\CloudClient\bin\cloudclient.bat

The assumption being that because CloudClient is deployed/installed by unzipping a file to a folder then copying this destination folder to another computer should work.

On the original (Windows Server 2012 R2) computer if I do a search for jansi this is what I get:

PS C:\> Get-ChildItem -Path D:\CloudClient -Filter "*jansi*.*" -Recurse

PS C:\> Get-ChildItem -Path C:\Windows -Filter "*jansi*.*" -Recurse -ErrorAction SilentlyContinue

    Directory: C:\Windows\Temp

Mode                LastWriteTime     Length Name

----                -------------     ------ ----

-----         12/5/2018   2:18 PM      19968 jansi-64-1307777946447382193.dll

-a---        12/13/2018  10:50 AM      19968 jansi-64-4666911674835746668.dll

-----        10/25/2018   1:11 PM      19968 jansi-64-4966134129686026623.dll

-----        10/25/2018   1:19 PM      19968 jansi-64-8297694176039042867.dll

PS C:\>

On the destination (Windows Server 2008 R2) computer the results are negative, i.e. nothing found.

Obviously I need to start over by installing CloudClient like normal, but now I'm curious to know how those DLLs got into the "C:\Windows\Temp" folder and/or is there a quick fix for this to save me the effort.

Reply
0 Kudos
eoinbyrne
Expert
Expert

As I said, the DLL gets extracted from the JAR file and copied to whatever local directory is referred to by java.io.tmpdir when the cloud client is started. There must be some flag or check (perhaps the presence of the cloudclient.properties...?) that is used to see if the DLL has been extracted before and therefore skip that action on the every execution after the first one (optimization I guess.... but hardly a major saving so why not just extract every time.....?)

In the case of those versions of Windows it looks to be c:\Windows\TEMP is the JAVA tmp dir --> cloudclient tries to load the DLL from there and fails on your 2008 instance as the path/file does not exist. This would be because since you copied a previously used version of the cloudclient pack.

Two options to fix I guess

1. Copy the DLL over to c:\windows\temp on the 2008 box and then it should work - resolving the missing DLL

2. Delete the cloudclient deployment from the 2008 box and deploy a fresh copy from the ZIP -  forcing a fresh deployment of the DLL to the JAVA tmp dir

Either should be fine at this stage

-Eoin

Reply
0 Kudos