Sonar does not download plugins - java

Someone knows why Sonar cannot download any plugins? I have a fresh v.3.7.4 installation. That's the first time I'm seeing this awesome server behaviour this way.
Trace:
2014.04.25 05:13:26 WARN o.s.s.p.PluginDownloader Fail to download the plugin (jira, version 1.2) from http://repository.codehaus.org/org/codehaus/sonar-plugins/sonar-jira-plugin/1.2/sonar-jira-plugin-1.2.jar
org.sonar.api.utils.SonarException: Fail to downloadhttp://repository.codehaus.org/org/codehaus/sonar-plugins/sonar-jira-plugin/1.2/sonar-jira-plugin-1.2.jar (no proxy)
at org.sonar.api.utils.HttpDownloader.failToDownload(HttpDownloader.java:143) ~[sonar-plugin-api-3.7.4.jar:na]
at org.sonar.api.utils.HttpDownloader.download(HttpDownloader.java:138) ~[sonar-plugin-api-3.7.4.jar:na]
at org.sonar.server.plugins.PluginDownloader.downloadRelease(PluginDownloader.java:126) ~[classes/:na]
at org.sonar.server.plugins.PluginDownloader.download(PluginDownloader.java:105) ~[classes/:na]
at org.sonar.server.ui.JRubyFacade.downloadPlugin(JRubyFacade.java:158) [classes/:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_55]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_55]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_55]
...
Environment:
Debian 7 x86
Java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) Server VM (build 24.55-b03, mixed mode)
Internet validation:
root#machine:/opt# wget http://repository.codehaus.org/org/codehaus/sonar-plugins/sonar-jira-plugin/1.2/sonar-jira-plugin-1.2.jar
--2014-04-25 05:21:58-- http://repository.codehaus.org/org/codehaus/sonar-plugins/sonar-jira-plugin/1.2/sonar-jira-plugin-1.2.jar
Resolving repository.codehaus.org (repository.codehaus.org)... 199.193.192.103
Connecting to repository.codehaus.org (repository.codehaus.org)|199.193.192.103|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1864762 (1.8M) [application/java-archive]
Saving to: `sonar-jira-plugin-1.2.jar'
100%[============================================================================>] 1,864,762 3.78M/s in 0.5s
2014-04-25 05:22:18 (3.78 MB/s) - `sonar-jira-plugin-1.2.jar' saved [1864762/1864762]

Deploy manually your jar files to the repository(mvn deploy:deploy-file), or if you allready done then:
Take a look in your local .m2 repository in the path: /org/codehaus/sonar-plugins/sonar-jira-plugin/1.2/
This path should be empty. If there you find files like *lastUpdated then delete all the content from the directory. Next time if you build the project then maven will download the files.
I expect you have a nexus or archiva or(whatewer) repository localy(writible for you) and you not work only with a settings.xml and .m2.

Related

Wildfly org.jboss.nio -> FileNotFoundException: Invalid file path with Windows Java JDK 11.0.15+10

Since the update to Eclipse Tamurin JDK 11.0.15+10 we notice a problem as soon a HTTP request reaches Wildfly 20.0.1.Final. The same behaviour exsists in Wildfly 26.1.0.Final This only happens with the JDK Windows version, the Linux JDK works fine.
As it is an "Invalid file path" error, an OS dependent BUG seems possible.
Until now SAP Machine is the only JDK that does not encounter this failure.
I'm still not sure if this is a JDK or a Wildfly problem...
You can check that when opening the Wildfly Management Interface.
ERROR [io.undertow.request] (External Management Request Threads -- 1) UT005071: Undertow request failed HttpServerExchange{ GET /management}: java.io.IOError: java.io.FileNotFoundException: Invalid file path
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels$4.run(Channels.java:1103)
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels$4.run(Channels.java:1093)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels.<clinit>(Channels.java:1093)
at io.undertow.core#2.1.3.Final//io.undertow.io.UndertowOutputStream.write(UndertowOutputStream.java:231)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.writeBuffer(BlockingSenderImpl.java:245)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.writeBuffer(BlockingSenderImpl.java:238)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.send(BlockingSenderImpl.java:75)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.send(BlockingSenderImpl.java:107)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainUtil.writeResponse(DomainUtil.java:89)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainApiHandler$1.doSendResponse(DomainApiHandler.java:177)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.ResponseCallback.sendResponse(ResponseCallback.java:32)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:232)
at io.undertow.core#2.1.3.Final//io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:91)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
at org.wildfly.security.elytron-private#1.12.1.Final//org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:328)
at org.wildfly.security.elytron-private#1.12.1.Final//org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:285)
at org.jboss.as.controller#12.0.3.Final//org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
at org.jboss.as.controller#12.0.3.Final//org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61)
at io.undertow.core#2.1.3.Final//io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at io.undertow.core#2.1.3.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)
at io.undertow.core#2.1.3.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
at java.base/java.lang.Thread.run(Thread.java:829)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: java.io.FileNotFoundException: Invalid file path
at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:231)
at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:126)
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels$4.run(Channels.java:1098)
... 29 more
JDK
Works with Wildfly
Eclipse Tamurin
no
Amazon Coretto
no
Azul Zulu
no
Bellsoft
no
Oracle OpenJDK
no
Oracle JDK
no
SAP Machine
yes
This is an issue in the JDK. You can wait for JDK 11.0.16 or downgrade to a lower version like JDK 11.0.14.
This is caused by a known JDK bug. You can work around the issue by setting Djdk.io.File.enableADS system property. In Intellij go to Run -> Edit configurations and paste -Djdk.io.File.enableADS=true in VM Options field.

Spark-Scala-Intellij java.lang.IllegalStateException: After installing macOS Big Sur Update

I am working on Spark Scala using IntelliJ IDE, Recently I installed Scala and Spark in my local and there was system update for mac-os version, so not sure what broke it.
I am getting error when I try to build my project now, Which was working fine a day before.
I checked for JRE vs JDK as suggested in other answers and I am sure that my project is pointing to JDK 1.8. Also I removed Scala and Spark from machine to make sure my machine is in same state as before. Still I am getting this error. Checked existing answers on same error, but no help.
[INFO] --- maven-surefire-plugin:2.7:test (default-test) # dotcom-jobs ---
[INFO] Tests are skipped.
[INFO]
[INFO] --- scalatest-maven-plugin:2.0.0:test (small-tests) # dotcom-jobs ---
*** RUN ABORTED ***
java.lang.IllegalStateException: Could not initialize plugin: interface org.mockito.plugins.MockMaker (alternate: null)
at org.mockito.internal.configuration.plugins.PluginLoader$1.invoke(PluginLoader.java:74)
at com.sun.proxy.$Proxy2.isTypeMockable(Unknown Source)
at org.mockito.internal.util.MockUtil.typeMockabilityOf(MockUtil.java:29)
at org.mockito.internal.util.MockCreationValidator.validateType(MockCreationValidator.java:22)
at org.mockito.internal.creation.MockSettingsImpl.validatedSettings(MockSettingsImpl.java:241)
at org.mockito.internal.creation.MockSettingsImpl.build(MockSettingsImpl.java:229)
at org.mockito.internal.MockitoCore.mock(MockitoCore.java:62)
at org.mockito.Mockito.spy(Mockito.java:1992)
at com.homelabs.sc.rbac.utils.ConfigHelper$class.configUtil(ConfigHelper.scala:26)
at com.homelabs.sc.rbac.base.BaseSmallTest.configUtil$lzycompute(BaseSmallTest.scala:7)
...
Cause: java.lang.IllegalStateException: Failed to load interface org.mockito.plugins.MockMaker implementation declared in sun.misc.CompoundEnumeration#517d4a0d
at org.mockito.internal.configuration.plugins.PluginInitializer.loadImpl(PluginInitializer.java:54)
at org.mockito.internal.configuration.plugins.PluginLoader.loadPlugin(PluginLoader.java:57)
at org.mockito.internal.configuration.plugins.PluginLoader.loadPlugin(PluginLoader.java:44)
at org.mockito.internal.configuration.plugins.PluginRegistry.<init>(PluginRegistry.java:22)
at org.mockito.internal.configuration.plugins.Plugins.<clinit>(Plugins.java:19)
at org.mockito.internal.util.MockUtil.<clinit>(MockUtil.java:24)
at org.mockito.internal.util.MockCreationValidator.validateType(MockCreationValidator.java:22)
at org.mockito.internal.creation.MockSettingsImpl.validatedSettings(MockSettingsImpl.java:241)
at org.mockito.internal.creation.MockSettingsImpl.build(MockSettingsImpl.java:229)
at org.mockito.internal.MockitoCore.mock(MockitoCore.java:62)
...
Cause: org.mockito.exceptions.base.MockitoInitializationException: Could not initialize inline Byte Buddy mock maker. (This mock maker is not supported on Android.)
Are you running a JRE instead of a JDK? The inline mock maker needs to be run on a JDK.
Java : 1.8
JVM vendor name : Oracle Corporation
JVM vendor version : 25.221-b11
JVM name : Java HotSpot(TM) 64-Bit Server VM
JVM version : 1.8.0_221-b11
JVM info : mixed mode
OS name : Mac OS X
OS version : 10.16
at org.mockito.internal.creation.bytebuddy.InlineByteBuddyMockMaker.<init>(InlineByteBuddyMockMaker.java:170)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at org.mockito.internal.configuration.plugins.PluginInitializer.loadImpl(PluginInitializer.java:49)
at org.mockito.internal.configuration.plugins.PluginLoader.loadPlugin(PluginLoader.java:57)
at org.mockito.internal.configuration.plugins.PluginLoader.loadPlugin(PluginLoader.java:44)
at org.mockito.internal.configuration.plugins.PluginRegistry.<init>(PluginRegistry.java:22)
...
Cause: java.lang.IllegalStateException: No compatible attachment provider is available
at net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:597)
at net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:581)
at net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:533)
at net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:510)
at org.mockito.internal.creation.bytebuddy.InlineByteBuddyMockMaker.<clinit>(InlineByteBuddyMockMaker.java:104)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
...
The problem was due to mac-os Big Sur update, contrary to what I thought the root cause is (installing scala).
So I solved this following this answer here at apple forum: https://developer.apple.com/forums/thread/666681
sudo rm -fr /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin
sudo rm -fr /Library/PreferencePanes/JavaControlPanel.prefpane

Tomcat9 complaining on class not found for javax.sql.DataSource class

Tomcat9 running on a Linux based VM, startup giving following error, when a Jdk11 compiled war file is deployed in tomcat. On start of tomcat following error occurs. How to resolve this class not found exception. Is specific module java.sql to be added explicitly?
Jul 22, 2020 1:49:45 AM org.apache.catalina.startup.Catalina start
SEVERE: The required Server component failed to start so Tomcat is unable to start.
org.apache.catalina.LifecycleException: Failed to start component [StandardServer[43004]]
at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198)
at org.apache.catalina.startup.Catalina.start(Catalina.java:633)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
Caused by: java.lang.NoClassDefFoundError: javax/sql/DataSource
at java.base/java.lang.ClassLoader.findBootstrapClass(Native Method)
at java.base/java.lang.ClassLoader.findBootstrapClassOrNull(ClassLoader.java:1258)
at java.base/java.lang.System$2.findBootstrapClassOrNull(System.java:2131)
at java.base/jdk.internal.loader.ClassLoaders$BootClassLoader.loadClassOrNull(ClassLoaders.java:118)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:616)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:640)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:616)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:576)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
I have tried adding '--add-modules java.sql' in the tomcat startup script. But still no difference. Also one strange thing is that when '-verbose:module' option is added it clearly shows that module java.sql is loaded, but still ends up with NoClassDefFoundError: javax/sql/DataSource.
find /usr/lib/jvm/adoptopenjdk-11-hotspot -name java.sql.jmod -exec jar tf '{}' \; | grep DataSource
classes/javax/sql/XADataSource.class
classes/javax/sql/ConnectionPoolDataSource.class
classes/javax/sql/DataSource.class
classes/javax/sql/CommonDataSource.class
java version :
$ java -version
openjdk version "11.0.7" 2020-04-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.7+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.7+10, mixed mode)
We have following block in server.xml
<Resource
name="jdbc/ILOraclePool"
auth="Container"
factory="com.xyz.tomcat.ucp.UcpDataSourceFactory" (this class extends oracle.ucp.jdbc.PoolDataSourceImpl)
type="oracle.ucp.jdbc.PoolDataSource"
description="main DB"
connectionFactoryClassName="oracle.jdbc.pool.OracleDataSource"
....
/>
First ensure that Oracle JDBC jar ojdbc8.jar, ucp.jar, and ons.jar from the same version (e.g. version 12.2) are present in $CATALINA_HOME/lib. Make sure that all three jar files are from the same database version. DO NOT mix the version of these jars. Always, try to use the latest JDBC driver and UCP in order to leverage the latest capabilities and performance improvements.
Also, I recommend you change the factory class to oracle.ucp.jdbc.PoolDataSourceImpl.
Hopefully, this should resolve the problem. In case it doesn't help, please post the JNDI lookup code and the DataSource configuration in web.xml.
I think tomcat is using some other JVM. Check that.
Open catalina.sh present in tomcat9/bin directory and export JAVA_HOME.
export JAVA_HOME=/usr/lib/jvm/adoptopenjdk-11-hotspot
For the managed resources in the application servers, it is better to copy the related libs(eg. the JDBC drivers) to the application server specific libs folder(eg. the Tomcat's catalina/lib, Glassfish's domains/yourdomain/lib etc) and registered it a host/domain scope or globally in the server config file.
As I know, some JDBC drivers do not work when it is packaged into the deployable war that is deployed into Tomcat. And when using Glassfish, Wildfly, etc., I always used the server tools(UI, CLI, Maven plugin, etc.) to register JDBC/Datasource related resources in the server config.
Update: I created a new repo to demo this usage in Spring Boot, check here.
oracle-jndi-ds-jar run as Spring Boot jar.
oracle-jndi-ds-war run as war in an external Apache Tomcat.
Both included an IT test on Java 11, Oracle XE 18.4.0, JNDI DataSource.
mvn verify -Pit
Have you tried moving the to context.xml ? Check out the Tomcat_Servlet code sample.

Impersonation issue after migrating from Oracle JDK 8 to Open JDK 8 in Cloudera cluster

Recently I moved from the Oracle JDK 8 to Open JDK 8 (version: openjdk-1.8.0.242.b08) for Cloudera. Cloudera version is 5.16.2. I have Kerberos and TLS enabled. When I am using Oracle JDK the below issue doesn't occur but when I switch to Open JDK then I am getting the below error. Please note that the proxy user is already enabled from the CM -> HDFS -> configuration.
JobHistoryServer
Error starting JobHistoryServer
org.apache.hadoop.yarn.exceptions.YarnRuntimeException: Error creating done directory: [hdfs://XXXX.YYY.COM:8020/user/history/done]
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.tryCreatingHistoryDirs(HistoryFileManager.java:680)
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.createHistoryDirs(HistoryFileManager.java:616)
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.serviceInit(HistoryFileManager.java:577)
at org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
at org.apache.hadoop.mapreduce.v2.hs.JobHistory.serviceInit(JobHistory.java:95)
at org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
at org.apache.hadoop.service.CompositeService.serviceInit(CompositeService.java:107)
at org.apache.hadoop.mapreduce.v2.hs.JobHistoryServer.serviceInit(JobHistoryServer.java:154)
at org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
at org.apache.hadoop.mapreduce.v2.hs.JobHistoryServer.launchJobHistoryServer(JobHistoryServer.java:229)
at org.apache.hadoop.mapreduce.v2.hs.JobHistoryServer.main(JobHistoryServer.java:239)
Caused by: org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.authorize.AuthorizationException): User: RZgWaGioVf#YYY.COM is not allowed to impersonate mapred/XXXX.YYY.COM#YYY.COM
at org.apache.hadoop.ipc.Client.call(Client.java:1504)
at org.apache.hadoop.ipc.Client.call(Client.java:1441)
at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:231)
at com.sun.proxy.$Proxy16.getFileInfo(Unknown Source)
at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:788)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:258)
at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:104)
at com.sun.proxy.$Proxy17.getFileInfo(Unknown Source)
at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:2168)
at org.apache.hadoop.fs.Hdfs.getFileStatus(Hdfs.java:133)
at org.apache.hadoop.fs.FileContext$14.next(FileContext.java:1143)
at org.apache.hadoop.fs.FileContext$14.next(FileContext.java:1139)
at org.apache.hadoop.fs.FSLinkResolver.resolve(FSLinkResolver.java:90)
at org.apache.hadoop.fs.FileContext.getFileStatus(FileContext.java:1139)
at org.apache.hadoop.fs.FileContext$Util.exists(FileContext.java:1604)
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.mkdir(HistoryFileManager.java:733)
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.tryCreatingHistoryDirs(HistoryFileManager.java:663)
This is a known bug I filed with openJDK.
"KerberosTicket client name refers wrongly to sAMAccountName in AD", Major loss of Function.
It is tracked here: https://bugs.openjdk.java.net/browse/JDK-8239385
This issue is resolved. The issue was due to the cross-realm referrals support for Kerberos (JDK-8215032). You need to set -Dsun.security.krb5.disableReferrals=true property of the service or to set this is java.security file.
Might be related to my problem: https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1861883
I also reported this to the OpenJDK bug report site (twice) but no reaction so far.
If your problem disappears after downgrading to OpenJDK 1.8.0 232 we've been hit by the same bug.

Java cryptography library sporadically fails to start

We have a Java web application that sporadically fails to find cryptographic libraries.
Currently restarting the application fixes the issue.
The following expections appear in the logs, see below for full stack trace.
java.lang.InternalError: Could not start up the CDSA libraries.
java.lang.NoClassDefFoundError: Could not initialize class com.apple.crypto.provider.HmacMD5
The application is built using Java 1.6.0_15 and is deployed to 1.6.0_13 running on
Mac OS X Server 10.5.8 (9L30)
Any ideas ?
Cheers
Jono
Build Java version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03-211)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02-83, mixed mode)
Deployed Jave version
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226)
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode)
Full stack trace:
java.lang.NoClassDefFoundError: Could not initialize class com.apple.crypto.provider.HmacMD5
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1881)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1782)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1047)
at com.apple.crypto.provider.HmacCore.<clinit>(HmacCore.java:26)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at java.security.Provider$Service.newInstance(Provider.java:1221)
at javax.crypto.Mac.a(DashoA13*..)
at javax.crypto.Mac.init(DashoA13*..)
at com.sun.net.ssl.internal.ssl.MAC.<init>(MAC.java:94)
at com.sun.net.ssl.internal.ssl.CipherSuite$MacAlg.newMac(CipherSuite.java:429)
at com.sun.net.ssl.internal.ssl.Handshaker.newWriteMAC(Handshaker.java:407)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.changeWriteCiphers(SSLSocketImpl.java:1791)
at com.sun.net.ssl.internal.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:607)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:868)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:794)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:226)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1112)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:506)
at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
Your error doesn't mean the class is not found. "Could not initialize class com.apple.crypto.provider.HmacMD5" means that the static intizializer block (static { ... }) caused an exception. Do you have access to the source code of MmacMD5?
We once had a similar problem where the static block failed due to a non-reachable X server - but only if no X-forwarding-enabled SSH session to the server was available. (The class was registering fonts to later use them for rendering images)
As "sfussenegger" wrote, it is related to the static {} method. If you can't find a helpful documentation or source code, try a decompiler (if the license is fine with that of course only). I saw problems with crypto libraries also related to the seed produced by secure random (System halts, till it obtains enough randomness). Maybe something like this is part of the problem.
Anyway, if you can't get rid of the problem, there is still bouncy castle as a free or IAIK as a commercial alternative. Not much, but maybe that helps...

Categories

Resources