Develop Reference

Sencha Cmd 5 - java.lang.NoClassDefFoundError

I need to use Sencha Cmd 5 (v5.1.3.61). I am getting an error after sencha app watch:
Sencha Cmd v5.1.3.61
[WRN] the following remote package repository directories did not initialize properly :
[WRN] - /home/radoslaw/bin/Sencha/Cmd/5.1.3.61/../repo/pkgs
[WRN] - /home/radoslaw/bin/Sencha/Cmd/5.1.3.61/../repo/.sencha
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
at com.sencha.util.StringUtil.toBase64(StringUtil.java:202)
at com.sencha.tools.generator.DataStoreImpl.get(DataStoreImpl.java:103)
at com.sencha.tools.generator.Generator$1.doMerge(Generator.java:461)
at com.sencha.tools.generator.Generator$Mode$3.dispatch(Generator.java:266)
at com.sencha.tools.generator.Generator.generateFileToFile(Generator.java:446)
at com.sencha.tools.generator.Generator.generateFileToDir(Generator.java:438)
at com.sencha.tools.generator.Generator.generateDirToDir(Generator.java:431)
at com.sencha.tools.generator.Generator.generateDirToDir(Generator.java:426)
at com.sencha.tools.generator.Generator.generate(Generator.java:145)
at com.sencha.tools.pkg.LocalRepository.init(LocalRepository.java:131)
at com.sencha.tools.pkg.LocalRepository.init(LocalRepository.java:185)
at com.sencha.command.environment.WorkspaceRepository.getLocalRepository(WorkspaceRepository.java:273)
at com.sencha.command.environment.WorkspaceRepository.getLocalRepository(WorkspaceRepository.java:286)
at com.sencha.command.environment.FrameworkEnvironment.loadFrameworkPackage(FrameworkEnvironment.java:207)
at com.sencha.command.environment.AppOrPackageEnvironment.loadFrameworkConfig(AppOrPackageEnvironment.java:52)
at com.sencha.command.environment.AppEnvironment.<init>(AppEnvironment.java:50)
at com.sencha.command.environment.BuildEnvironment.load(BuildEnvironment.java:100)
at com.sencha.command.environment.BuildEnvironment.load(BuildEnvironment.java:124)
at com.sencha.command.environment.BuildEnvironment.load(BuildEnvironment.java:70)
at com.sencha.command.Sencha.loadBuildEnvironment(Sencha.java:426)
at com.sencha.command.Sencha.main(Sencha.java:128)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.DatatypeConverter
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 21 more
Operating System: Linux Mint 20 Cinnamon
Linux Karnel: 5.4.0-26-generic
Java version:
openjdk version "11.0.7" 2020-04-14
OpenJDK Runtime Environment (build 11.0.7+10-post-Ubuntu-3ubuntu1)
OpenJDK 64-Bit Server VM (build 11.0.7+10-post-Ubuntu-3ubuntu1, mixed mode, sharing)
I understand that boils down to the Java version.
The solutions I found did not come down to the same problem.
Has anyone encountered such a problem? What will be the simplest solution?

Log4j2/Slf4j and Java 11

I'm currently trying to build an app with log4j/slf4j and java 11 but I'm facing this problem at runtime:
2018-12-10 22:09:27,225 main INFO Cannot initialize scripting support because this JRE does not support it. java.lang.NoClassDefFoundError: javax/script/ScriptEngineManager
at org.apache.logging.log4j.core#2.11.1/org.apache.logging.log4j.core.script.ScriptManager.<init>(ScriptManager.java:69)
at org.apache.logging.log4j.core#2.11.1/org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:216)
at org.apache.logging.log4j.core#2.11.1/org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:250)
at org.apache.logging.log4j.core#2.11.1/org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:547)
at org.apache.logging.log4j.core#2.11.1/org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:619)
at org.apache.logging.log4j.core#2.11.1/org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:636)
at org.apache.logging.log4j.core#2.11.1/org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
at org.apache.logging.log4j.core#2.11.1/org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
at org.apache.logging.log4j.core#2.11.1/org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j/org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
at org.apache.logging.log4j/org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121)
at org.apache.logging.log4j.slf4j#2.11.1/org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:49)
at org.apache.logging.log4j/org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
at org.apache.logging.log4j.slf4j#2.11.1/org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
at org.slf4j/org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:355)
at org.slf4j/org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:380)
at fr.mrcraftcod.nameascreated/fr.mrcraftcod.nameascreated.NameAsCreated.<clinit>(NameAsCreated.java:39)
Caused by: java.lang.ClassNotFoundException: javax.script.ScriptEngineManager
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 17 more
The code that is at the origin of this is the initialization of my logger:
private static final Logger LOGGER = LoggerFactory.getLogger(NameAsCreated.class);
I have dependencies on:
org.apache.logging.log4j:log4j-api:2.11.1
org.apache.logging.log4j:log4j-core:2.11.1
org.apache.logging.log4j:log4j-slf4j18-impl:2.11.1
A maven project that depends on org.slf4j:slf4j-api:1.8.0-beta2
I'm on OSX Mojave with Java version:
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment AdoptOpenJDK (build 11+28-201810021910)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11+28-201810021910, mixed mode)
Does someone have an idea of what I'm doing wrong and how I can solve this?

According to the Log4j documentation:
Log4j provides support for JSR 223 scripting languages to be used in some of its components.
and as said in the comments by Alan Bateman from Java 9 you have to add explicitly the java scripting module either with --add-modules java.scripting or in module-info.java.
Note also that the module jdk.scripting.nashorn is deprecated in Java 11 and will be removed in a future release.

Java 9 Runtime Exception calling org.glassfish.jersey.server.ResourceConfig

My app works great with java 1.8 (and earlier), however when I rebuilt the application to use java 9, I receive the following stack trace. The reason for the update is because I need to use the new ProcessHandle.current(), which does not exist in earlier versions.
c:\>java -jar ./build/bin/DataMover.jar
DataMover Service: starting...
Exception in thread "main" java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
Caused by: java.lang.NoClassDefFoundError: org/glassfish/jersey/server/ResourceConfig
at dataMoverServerPackage.Main.main(Unknown Source)
... 5 more
Caused by: java.lang.ClassNotFoundException: org.glassfish.jersey.server.ResourceConfig
at java.base/java.net.URLClassLoader.findClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
... 6 more
For whomever is curious, here is the java version output.
c:\>java -version
java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)
Here is the relevant main() function.
public static void main(String[] args)
{
try
{
...
final ResourceConfig resourceConfig = new ResourceConfig(DataMoverServerResource.class);
I did research and read that the big difference between Java 6,7,8 and Java 9 is modules. In particular earlier versions of Java included the Java EE JDK, whereas Java 9 includes the java.se module, not the EE. All com.sun.* classes are inaccessible in Java 9, as I read. These pieces of information may or may not be relevant. I do not know the internal makeup of the jersey.server API, just some articles talked of that.
I am using a jar in jar loader, so the jersey stuff is in the base jar.
I am torn between an internal dependency issue on Jersey or the jersey jar. The loader seems happy just fails later at the java.base/jdk.internal, which tells me a module might be missing.
If there were an internal module, such as java.xml.bind, like I read in one post, which is included in Java EE, then the exception trace would indicate that and I would know to add that module using the --add-module option to java, such as --add-module java.xml.bind, but that is not the case here, at least with that module.
Here is a link to one possibly relevant article. Maybe the java.net is the problem, much like the at javax.xml.bind at the bottom of the stack trace in that question was the underlying cause. I discounted the ext folder answer in this question, as that question pertained to 1.8, which works for me and I have jar-in-jar. I note the question here because it keeps turning up on searches. This question was also not relevant, though similar. The list goes on.
I use Eclipse, but build using ant. The Jersey stuff libraries are in my Maven .m2 folder. I did right click on my project and select Maven > Update. That is at 2.7.
I came across this site, which talks about Java 9 migration. In the site, I read that if you add java.se.ee, you will have access to all Java EE modules. That recommendation failed, same output. The command that I tried was:
java --add-modules java.se.ee -jar ./build/bin/DataMover.jar
I did check SO and quite a few other sites but have turned up empty so far. Thoughts?

Java security error Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_OPERATION_ACTIVE

We are seeing java security error randomly on our java job.
This error comes randomly when we pick xml files from windows server and parse them on Linux server trying to save in MongoGridFS.
The problem is when we restart this job it start working fine again for same data.
update() failed
java.security.ProviderException: update() failed
at
sun.security.pkcs11.P11Digest.engineUpdate(P11Digest.java:228)
at java.security.MessageDigest$Delegate.engineUpdate(MessageDigest.java:568)
at java.security.MessageDigest.update(MessageDigest.java:323)
at com.mongodb.gridfs.GridFSInputFile.dumpBuffer(GridFSInputFile.java:280)
at com.mongodb.gridfs.GridFSInputFile.saveChunks(GridFSInputFile.java:229)
at com.mongodb.gridfs.GridFSInputFile.save(GridFSInputFile.java:178)
at com.mongodb.gridfs.GridFSInputFile.save(GridFSInputFile.java:160)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_OPERATION_ACTIVE
at sun.security.pkcs11.wrapper.PKCS11.C_DigestInit(Native Method)
at sun.security.pkcs11.P11Digest.engineUpdate(P11Digest.java:210)
... 16 more
java version "1.7.0_45"
OpenJDK Runtime Environment (rhel-2.4.3.3.el6-x86_64 u45-b15)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description: CentOS release 6.5 (Final)
Could you please help me with this issue as it has become critical.
Thanks
Virendra Agarwal

Sonar does not download plugins

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.