I recently upgraded to OpenJDK 9 but am now encountering errors with CI build.
Exception in thread "main" javax.net.ssl.SSLException:
java.lang.RuntimeException: Unexpected error:
java.security.InvalidAlgorithmParameterException: the trustAnchors
parameter must be non-empty
I tried to symlinking
/usr/lib/jvm/java-9-openjdk-amd64/lib/security/cacerts
/etc/ssl/certs/java/cacerts
But did not work, can confirm Slim version works but i'd rather not use this. Is there any quick hack or work around to use until the issue is resolved down the line?
Related
I'm trying to run IntegratedWebLogicServer using JDeveloper Version 12.2.1.4.0, and I have the following message:
ERROR: An error occurred while building the default domain.
And the log shows:
BuildDefaultDomain1.py 2020-02-10 11:53:05
cmd.exe /c ""C:\Oracle\Middleware\Oracle_Home\oracle_common\common\bin\wlst.cmd" "C:\Users\nauana.nonato\AppData\Roaming\JDeveloper\system12.2.1.4.42.190911.2248\o.j2ee.adrs\BuildDefaultDomain1.py""
Cannot run program "cmd.exe" (in directory "C:\Oracle\Middleware\Oracle_Home\oracle_common\common\bin"): Malformed argument has embedded quote: "C:\Oracle\Middleware\Oracle_Home\oracle_common\common\bin\wlst.cmd" "C:\Users\nauana.nonato\AppData\Roaming\JDeveloper\system12.2.1.4.42.190911.2248\o.j2ee.adrs\BuildDefaultDomain1.py"
java.io.IOException: Cannot run program "cmd.exe" (in directory "C:\Oracle\Middleware\Oracle_Home\oracle_common\common\bin"): Malformed argument has embedded quote: "C:\Oracle\Middleware\Oracle_Home\oracle_common\common\bin\wlst.cmd" "C:\Users\nauana.nonato\AppData\Roaming\JDeveloper\system12.2.1.4.42.190911.2248\o.j2ee.adrs\BuildDefaultDomain1.py"
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at oracle.jdevimpl.adrs.weblogic.wlst.ScriptRunnerImpl.runScript(ScriptRunnerImpl.java:106)
at oracle.jdevimpl.adrs.weblogic.builder.DomainScriptRunnerImpl.runScript(DomainScriptRunnerImpl.java:146)
at oracle.jdevimpl.adrs.weblogic.builder.DefaultDomainBuilder.createDomain(DefaultDomainBuilder.java:606)
at oracle.jdevimpl.adrs.weblogic.builder.DefaultDomainBuilder.build(DefaultDomainBuilder.java:274)
at oracle.jdevimpl.adrs.weblogic.builder.DefaultDomainBuilder$1.run(DefaultDomainBuilder.java:225)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443)
at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058)
Caused by: java.lang.IllegalArgumentException: Malformed argument has embedded quote: "C:\Oracle\Middleware\Oracle_Home\oracle_common\common\bin\wlst.cmd" "C:\Users\nauana.nonato\AppData\Roaming\JDeveloper\system12.2.1.4.42.190911.2248\o.j2ee.adrs\BuildDefaultDomain1.py"
at java.lang.ProcessImpl.needsEscaping(ProcessImpl.java:279)
at java.lang.ProcessImpl.createCommandLine(ProcessImpl.java:202)
at java.lang.ProcessImpl.<init>(ProcessImpl.java:436)
at java.lang.ProcessImpl.start(ProcessImpl.java:140)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
... 9 more
What should I do?
Follow the following steps to fix this issues in 12.2.1.4
Go to Oracle_Home\jdeveloper\ide\bin folder.
Edit ide.conf file.
Under # Other OSGi configuration options for locating bundles and boot delegation section (or any other section) add the following line
AddVMOption -Djdk.lang.Process.allowAmbiguousCommands=true
Restart JDeveloper.
I am having the same problem as you. I am installing Oralce SOA Quick Start 12c version 12.1
Version JDK: javac 1.8.0_251
To solve this problem. You set parameters in enviroment:
-Djdk.lang.Process.allowAmbiguousCommands=true
set JAVA_TOOL_OPTIONS=-Djdk.lang.Process.allowAmbiguousCommands=true
good luck: ManhKM
My Jenkins server was switched to now using HTTPS. However, now when trying to run jenkins-cli.jar, I get the following error:
Exception in thread "main" java.io.IOException: Failed to connect to https://ncs-jenkins.cisco.com/
at hudson.cli.CLI.getCliTcpPort(CLI.java:266)
at hudson.cli.CLI.<init>(CLI.java:126)
at hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72)
at hudson.cli.CLI._main(CLI.java:466)
at hudson.cli.CLI.main(CLI.java:382)
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:902)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1208)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1235)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1219)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:440)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
at hudson.cli.CLI.getCliTcpPort(CLI.java:264)
... 4 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(InputRecord.java:482)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:883)
... 11 more
Is there any way to use Jenkins CLI over HTTPS?
This happens, for example when I try to run even just the help command:
java -jar jenkins-cli.jar -noCertificateCheck -s https://ncs-jenkins.cisco.com:8443/ -i /home/auto/.ssh/id_rsa help
This works for me:
java -jar jenkins-cli.jar -noCertificateCheck -auth #jenkins_creds.txt -s https://jenkins.example.com help
(If I omit -auth then I get an expected error about the need to authenticate to the Jenkins instance, but that doesn't seem relevant to you error.)
java-version
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
Jenkins version: 2.138.3
I am wondering whether you have some other piece of equipment between your cli and your Jenkins server that cuts the connection if HTTPS cert verification fails.
I encountered the same problem on one of my jenkins slaves.
Since the slaves were supposed to be identical, I started investigating the slightest differences between the machines.
As it turns out, the java version was slightly different:
java-1.7.0-openjdk-1.7.0.75.x86_64 - On the working machine
java-1.7.0-openjdk-1.7.0.85.x86_64 - On the failing one.
I reverted back to the earlier openjdk version and the problem was fixed.
Since you asked the question only a few days ago, I suspect we've encountered the same problem.
To check your version:
java -showversion -verbose 2>&1 | head -1
To install the previous openjdk version (on centos):
yum install java-1.7.0-openjdk-devel-1:1.7.0.75-2.5.4.0.el6_6.x86_64
If you are using a valid SSL cert.
Checkout the jenkins-cli commands returning connect timed out
PS: This is not a solution but may be a workaround until a solution is found.
when I am starting glass fish server through command prompt I am getting an
error. I am using jdk 1.5 and jdk1.6 also. Due to java version am I getting that error or any other reason.
I am using two tomcat server also that port no is 8080 and 8081.
For glass fish-domain purpose I am using 4545 port number.
Error starting domain mydomain1.
The server exited prematurely with exit code 1.
Before it died, it produced the following output:
FATAL ERROR in native method: processing of -javaagent failed
java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:133)
Exception in thread "main"
This is the important bit.
java.lang.UnsupportedClassVersionError: Bad version number in .class file
It means that the class loader does not understand the version number of one of the ".class" files that it is trying to load.
The most likely explanation is that you are trying to load classes that have been compiled on a Java 7 development platform on an earlier (e.g. Java 5 or Java 6) JRE / JVM installation. You either need to upgrade your execution platform to Java 7 (best option), or downgrade your development platform to Java 5 or Java 6 (or whatever you are using).
Note that both Java 5 and Java 6 have reached "end of life", and there will not be any more patch releases available ... unless you take out an Oracle Java support contract.
Samples run fine on my Windows 7.
However I get the following error on my Ubuntu machine:
Exception in thread "main" java.lang.NoSuchMethodError: org.joda.time.LocalDateTime.toDate()Ljava/util/Date;
at com.alvazan.orm.api.base.spi.UniqueKeyGenerator.generateKey(UniqueKeyGenerator.java:47)
at com.alvazan.orm.api.base.spi.UniqueKeyGenerator.generateNewKey(UniqueKeyGenerator.java:42)
at com.alvazan.orm.api.base.spi.UniqueKeyGenerator.generateNewKey(UniqueKeyGenerator.java:21)
at com.alvazan.orm.impl.meta.data.MetaIdField.fillInAndFetchId(MetaIdField.java:106)
at com.alvazan.orm.impl.meta.data.MetaIdField.translateToColumn(MetaIdField.java:56)
at com.alvazan.orm.impl.meta.data.MetaClassSingle.translateToRow(MetaClassSingle.java:82)
at com.alvazan.orm.layer0.base.BaseEntityManagerImpl.putImpl(BaseEntityManagerImpl.java:117)
at com.alvazan.orm.layer0.base.BaseEntityManagerImpl.put(BaseEntityManagerImpl.java:100)
at com.example.PlayORMExample.createTestData(PlayORMExample.java:89)
at com.example.PlayORMExample.main(PlayORMExample.java:31)
I looked at similar questions on the "stack", but they do not seem to apply to my case.
you either
have the wrong version of the joda-time jar OR
have two joda time jars one of which is the wrong version
later,
Dean (I am a committer on PlayOrm).
Got the following stacktrace when launching gradle 1.1, anyone know how to resolve them:
Exception in thread "main" java.lang.NullPointerException
at org.gradle.wrapper.BootstrapMainStarter.findLauncherJar(BootstrapMainStarter.java:37)
at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:28)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:130)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:47)
I think the automatic unzip of the dists/gradle-1.1-bin/13d7lnhcrghv2i5e54el41jpgr/gradle-1.1-bin.zip might be failing. I checked permissions and that I have access to that directory.
If I unzip manually, then I get the following error:
Exception in thread "main" java.lang.RuntimeException: Gradle distribution 'http://services.gradle.org/distributions/gradle-1.1-bin.zip' contains too many directories. Expected to find exactly 1 directory.
at org.gradle.wrapper.Install.createDist(Install.java:73)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:129)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:47)
I did a google search for gradle nullpointerexception and it mentioned the JAVA_HOME needs to be set for compiling, but I've already checked it is set correctly and been able to compile stuff with ant in that environment.
I was getting exactly same error and I changed the version of gradle that I was using. Inside my gradle-wrapper.properties, changed version 2.4 to 2.2.1 and error is gone.