Failed startup of context c.g.g.d.s.j.WebAppContextWithReload - java

I need help with an issue I have no idea how to resolve. Your help will be greatly appreciated.
I just added log4j2 jars (log4j-api-2.10.0.jar, log4j-core-2.10.0.jar) to my Web app and it started running into this problem in my dev. Later I added log4j-web-2.10.0.jar and tried, it still fails with the same message.
Here's my environment:
IDE: Eclipse Oxygen2
JDK: 1.8.0_162
Jetty (embedded in Eclipse): jetty-9.2.z-SNAPSHOT
OS: Win 10 (64bit)
Framework: GWT 2.8.2
Stack trace (partial):
[WARN] Failed startup of context c.g.g.d.s.j.WebAppContextWithReload#3a24f397{/,file:<project_path>/war/,STARTING}{<project_path>\war}
MultiException[java.lang.RuntimeException: Error scanning entry META-INF/versions/9/org/apache/logging/log4j/util/ProcessIdUtil.class from jar file:<project_path>/war/WEB-INF/lib/log4j-api-2.10.0.jar, java.lang.RuntimeException: Error scanning entry META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class from jar file:<project_path>/war/WEB-INF/lib/log4j-api-2.10.0.jar, java.lang.RuntimeException: Error scanning entry module-info.class from jar file:<project_path>/war/WEB-INF/lib/log4j-api-2.10.0.jar]
at org.eclipse.jetty.annotations.AnnotationConfiguration.scanForAnnotations(AnnotationConfiguration.java:536)
at org.eclipse.jetty.annotations.AnnotationConfiguration.configure(AnnotationConfiguration.java:447)
at org.eclipse.jetty.webapp.WebAppContext.configure(WebAppContext.java:479)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1337)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
.
.
.
Caused by: MultiException[java.lang.RuntimeException: Error scanning entry META-INF/versions/9/org/apache/logging/log4j/util/ProcessIdUtil.class from jar file:<project_path>/WEB-INF/lib/log4j-api-2.10.0.jar, java.lang.RuntimeException: Error scanning entry META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class from jar file:<project_path>/WEB-INF/lib/log4j-api-2.10.0.jar, java.lang.RuntimeException: Error scanning entry module-info.class from jar file:<project_path>/WEB-INF/lib/log4j-api-2.10.0.jar]
at org.eclipse.jetty.annotations.AnnotationParser.parseJar(AnnotationParser.java:899)
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:831)
at org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call(AnnotationConfiguration.java:163)
at org.eclipse.jetty.annotations.AnnotationConfiguration$1.run(AnnotationConfiguration.java:548)

Copied from https://github.com/eclipse/jetty.project/issues/2192, (with additional edits)
This is related to your use of a JEP-238 Multi-Release JAR.
Notice the path ..
META-INF/versions/9/org/apache/logging/log4j/util/ProcessIdUtil.class
The META-INF/versions/<java.specification.version>/* path prefix tells you that the classes below that path are for that specific version of Java, replacing potentially the same named classes in the top level JAR.
Issue #1797 is where this was first reported and fixed.
It was fixed for ...
jetty-9.3.22.v20171030 - 30 October 2017
jetty-9.4.8.v20171121 - 21 November 2017
Since Jetty 9.2.x is end of life, there will be no backport to support JEP-238 on Jetty 9.2.x.
Your choices are to upgrade to one of the supported versions listed above, or downgrade your version of log4j to one that does not use JEP-238 Multi-Release JAR Files.
Also of note, the log4j JEP-238 Multi-Release JAR file you are using is also a Java 9 JPMS module.
The presence module-info.class indicates that.
Support in Jetty to ignore module-info.class during bytecode scanning was fixed in Issue #1692

Related

How to get KQueue to be available in Java in OSX?

My packages are as following:
implementation("io.netty:netty-transport-native-epoll:$nettyVersion")
implementation("io.netty:netty-transport-native-kqueue:$nettyVersion")
implementation("io.netty:netty-transport-native-epoll:$nettyVersion:linux-aarch_64")
implementation("io.netty:netty-transport-native-epoll:$nettyVersion:linux-x86_64")
implementation("io.netty:netty-transport-native-kqueue:$nettyVersion:osx-x86_64")
Gradle showing the package getting installed correctly: (where <source> is the path to our internal library storage)
Cached resource <source>/releases/io/netty/netty-transport-native-kqueue/4.1.78.Final/netty-transport-native-kqueue-4.1.78.Final-osx-x86_64.jar is up-to-date (lastModified: Fri Jun 24 17:45:28 PDT 2022).
Gradle output showing the system:
------------------------------------------------------------------------
Detecting the operating system and CPU architecture
------------------------------------------------------------------------
os.detected.name=osx
os.detected.arch=x86_64
os.detected.version=12.4
os.detected.version.major=12
os.detected.version.minor=4
os.detected.classifier=osx-x86_64
Simplest way I can reproduce is:
KQueue.isAvailable()
returns false.
If I run the following to get more information:
KQueue.unavailabilityCause().printStackTrace();
I get: (removed repeating or unnecessary stack traces)
java.lang.UnsatisfiedLinkError: could not load a native library: netty_transport_native_kqueue_x86_64
at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:239)
at io.netty.channel.kqueue.Native.loadNativeLibrary(Native.java:155)
...
Suppressed: java.lang.UnsatisfiedLinkError: no netty_transport_native_kqueue_x86_64 in java.library.path: /Users/kdilsiz/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
...
Am I not supposed to be able to run this code? What am I missing?
If I search online for the error, it shows outdated Netty package loading errors (only showing up in debug level logging). This is NOT my problem. The package loads correctly when I run gradle and I can see it is being cached/loaded with gradle -info --refresh-dependencies.
It was due to one of the dependencies importing netty-all. This was causing the Kqueue packages to be imported twice and with different versions.
The problem was that I did not fully read the stack trace from:
KQueue.unavailabilityCause().printStackTrace();
In the end of that stack trace, it said:
Caused by: java.lang.IllegalStateException: Multiple resources found for 'META-INF/native/libnetty_transport_native_kqueue_x86_64.jnilib' with different content:
...
After that, I was able to find where the package was coming from and fix it. Then I was able to locally run the Java Code to run domain socket and test it locally.
I used IntelliJ to run it after the fix. (VsCode had a problem even after the fix, hence wanted to mention it)

Apache Ignite - error 'JavaLoggerFileHandler' when running Spark shell

I am starting spark-shell (of spark 2.2) and added bunch of jars in spark-shell command (from Ignite 2.1 directory).
Still getting error:
Can't load log handler "org.apache.ignite.logger.java.JavaLoggerFileHandler"
Also followed recommendation from here:
https://apacheignite.readme.io/v1.2/docs/installation--deployment
# Optionally set IGNITE_HOME here.
# IGNITE_HOME=/path/to/ignite
IGNITE_LIBS="${IGNITE_HOME}/libs/*"
for file in ${IGNITE_HOME}/libs/*
do
if [ -d ${file} ] && [ "${file}" != "${IGNITE_HOME}"/libs/optional ]; then
IGNITE_LIBS=${IGNITE_LIBS}:${file}/*
fi
done
export SPARK_CLASSPATH=$IGNITE_LIBS
Also set logging to only ERROR as well but still getting error:
Can't load log handler "org.apache.ignite.logger.java.JavaLoggerFileHandler"
java.lang.ClassNotFoundException: org.apache.ignite.logger.java.JavaLoggerFileHandler
java.lang.ClassNotFoundException: org.apache.ignite.logger.java.JavaLoggerFileHandler
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.util.logging.LogManager$5.run(LogManager.java:965)
at java.security.AccessController.doPrivileged(Native Method)
Looks like you use documentation for an old Ignite version 1.2, while you use Ignite 2.1. Check the documentation for the latest version here: https://apacheignite-fs.readme.io/v2.2/docs/installation-deployment
Also, please make sure that have configured IGNITE_HOME in your environment. JavaLoggerFileHandler placed in the ignite-core module, looks like spark classpath doesn't see any Ignite lib at all.
The documentation describe the issue here:
https://apacheignite-fs.readme.io/v2.2/docs/troubleshooting
This issue appears when you do not have any loggers included in classpath and Ignite tries to use standard Java logging. By default Spark loads all user jar files using separate class loader. Java logging framework, on the other hand, uses application class loader to initialize log handlers. To resolve this, you can either add ignite-log4j module to the list of the used jars so that Ignite would use Log4j as a logging subsystem, or alter default Spark classpath as described

org.usb4java.LoaderException: Native library not found in classpath error

Am an trying to use the usb4java library with a project running in Ubuntu 64bit. I am getting the following error;
30 Jul 2015 09:46:16,225 INFO Controller : Working Directory: /opt/dock
Exception in thread "main" java.lang.ExceptionInInitializerError
at uk.co.swimtag.control.Controller.findDevice(Controller.java:755)
at uk.co.swimtag.control.Controller.startApplication(Controller.java:150)
at uk.co.swimtag.control.Controller.main(Controller.java:104)
Caused by: org.usb4java.LoaderException: Native library not found in classpath: /org/usb4java/linux-x86_64/libusb4java.so
at org.usb4java.Loader.extractLibrary(Loader.java:281)
at org.usb4java.Loader.load(Loader.java:358)
at org.usb4java.LibUsb.<clinit>(LibUsb.java:640)
... 3 more
Here are the two jars in the manifest file, and am sure the x86_64 lib is in the project;
lib/mail.jar
lib/gson-1.6.jar
lib/usb4java-1.2.0.jar
lib/libusb4java-1.2.0-linux-x-86_64.jar
conf/
Any one had similar problems with usb4java. Probably something silly I have missed.
Thanks
Maybe it is just a typo. But if you're sure the jar with natives is on your CLASSPATH, it may be that in your manifest file you wrote: libusb4java-1.2.0-linux-x-86_64.jar instead of libusb4java-1.2.0-linux-x86_64.jar

RAD 9 upgrade causes publishing error on jaxws app

I have a webapp with a web service in it and little else being converted from RAD 8 to RAD 9. I go to publish this app, and I get the following warning. Yet, the app does publish, although it needs a restart. I created the web service and everything in RAD. I am not running these tools manually. I don't really understand what I am supposed to do with this error.
Publishing failed
deployFailure
Deploying eNotesApp
Deployment from com.ibm.ast.ws.jaxws.deployer.JAXWSDeployer had errors:
Deployment from com.ibm.ast.ws.jaxws.deployer.JAXWSDeployer had errors:
Deployment from com.ibm.ast.ws.jaxws.deployer.JAXWSDeployer had errors:
Deployment from com.ibm.ast.ws.jaxws.deployer.JAXWSDeployer had errors:
Errors occurred during wsgen.
Errors occurred during wsgen.
error: compilation failed, errors should have been reported
warning: The apt tool and its associated API are planned to be
removed in the next major JDK release. These features have been
superseded by javac and the standardized annotation processing API,
javax.annotation.processing and javax.lang.model. Users are
recommended to migrate to the annotation processing features of
javac; see the javac man page for more information.
Note: ap round: 1
Problem encountered during annotation processing;
see stacktrace below for more information.
java.lang.NullPointerException
at com.ibm.jtc.jax.tools.ws.processor.modeler.annotation.WebServiceVisitor.isLegalType(WebServiceVisitor.java:794)
at com.ibm.jtc.jax.tools.ws.processor.modeler.annotation.WebServiceVisitor.isLegalParameter(WebServiceVisitor.java:694)
at com.ibm.jtc.jax.tools.ws.processor.modeler.annotation.WebServiceVisitor.isLegalMethod(WebServiceVisitor.java:661)
at com.ibm.jtc.jax.tools.ws.processor.modeler.annotation.WebServiceVisitor.methodsAreLegal(WebServiceVisitor.java:611)
at com.ibm.jtc.jax.tools.ws.processor.modeler.annotation.WebServiceVisitor.isLegalImplementation(WebServiceVisitor.java:529)
at com.ibm.jtc.jax.tools.ws.processor.modeler.annotation.WebServiceVisitor.shouldProcessWebService(WebServiceVisitor.java:332)
at com.ibm.jtc.jax.tools.ws.processor.modeler.annotation.WebServiceVisitor.visitClassDeclaration(WebServiceVisitor.java:123)
at com.sun.tools.apt.mirror.declaration.ClassDeclarationImpl.accept(ClassDeclarationImpl.java:125)
at com.ibm.jtc.jax.tools.ws.processor.modeler.annotation.WebServiceAP.buildModel(WebServiceAP.java:329)
at com.ibm.jtc.jax.tools.ws.processor.modeler.annotation.WebServiceAP.process(WebServiceAP.java:270)
at com.sun.mirror.apt.AnnotationProcessors$CompositeAnnotationProcessor.process(AnnotationProcessors.java:83)
at com.sun.tools.apt.comp.Apt.main(Apt.java:492)
at com.sun.tools.apt.main.AptJavaCompiler.compile(AptJavaCompiler.java:282)
at com.sun.tools.apt.main.Main.compile(Main.java:1139)
at com.sun.tools.apt.main.Main.compile(Main.java:1001)
at com.sun.tools.apt.Main.processing(Main.java:125)
at com.sun.tools.apt.Main.process(Main.java:115)
at com.sun.tools.apt.Main.process(Main.java:97)
at com.ibm.jtc.jax.tools.ws.wscompile.WsgenTool.buildModel(WsgenTool.java:223)
at com.ibm.jtc.jax.tools.ws.wscompile.WsgenTool.run(WsgenTool.java:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:607)
at com.ibm.ast.ws.jaxws.emitter.jws22.v85.command.AbstractWsGenCommand.execute(AbstractWsGenCommand.java:134)
at com.ibm.ast.ws.jaxws.emitter.command.WebServiceAPCommand.execute(WebServiceAPCommand.java:50)
at com.ibm.ast.ws.jaxws.deployer.JAXWSWebServiceAPInvoker.executeWSAPForProject(JAXWSWebServiceAPInvoker.java:141)
at com.ibm.ast.ws.jaxws.deployer.JAXWSDeployer.execute(JAXWSDeployer.java:98)
at org.eclipse.jst.j2ee.internal.deploy.J2EEDeployOperation.deploy(J2EEDeployOperation.java:183)
at org.eclipse.jst.j2ee.internal.deploy.J2EEDeployOperation.execute(J2EEDeployOperation.java:113)
at com.ibm.etools.server.task.ejbdeploy.internal.JEEDeployPublisher.execute(JEEDeployPublisher.java:207)
at org.eclipse.wst.server.core.internal.Publisher.execute(Publisher.java:176)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.executePublishers(ServerBehaviourDelegate.java:1277)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:960)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:774)
at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:3153)
at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:345)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Deployment from com.ibm.ast.ws.deployer.WSDeployer completed successfully
OK
OK
OK
Bizarrely, this seems to be the result of some leftover artifacts from when I was working with policy sets in RAD 8. The result was that the META-INF directory had some files to describe the policy sets (though they were set to inoccuous settings). Once removed, the warning went away. Evidently something about these RAD 8 generated files triggered the behavior, even though they did not do so in RAD 8.

Unity-Android _ CommandInvokationFailure: Unable to convert classes into dex format

i'm using Windows 7, jdk 1.8.0 (64bit), jre 8 (64bit), Unity Pro 4.3.4f1 and Android SDK 22.6.1
All are updated softwares.
All works fine but when i use StartApp sdk, this error comes. No extra plugin is used, only the SDK provided by the StartApp ad.
Error building Player: CommandInvokationFailure: Unable to convert classes into dex format. See the Console for details.
C:\Program Files\Java\jdk1.8.0\bin\java.exe -Xmx1024M -Dcom.android.sdkmanager.toolsdir="D:/android-sdks\tools" -Dfile.encoding=UTF8 -jar "C:/Program Files (x86)/Unity/Editor/Data/BuildTargetTools/AndroidPlayer\sdktools.jar" -
stderr[
UNEXPECTED TOP-LEVEL EXCEPTION:
java.lang.IllegalArgumentException: already added: Lcom/unity3d/player/a$1;
at com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:122)
at com.android.dx.dex.file.DexFile.add(DexFile.java:161)
at com.android.dx.command.dexer.Main.processClass(Main.java:685)
at com.android.dx.command.dexer.Main.processFileBytes(Main.java:634)
at com.android.dx.command.dexer.Main.access$600(Main.java:78)
at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:572)
at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)
at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)
at com.android.dx.cf.direct.ClassPathOpener.processDirectory(ClassPathOpener.java:229)
at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:158)
at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)
at com.android.dx.command.dexer.Main.processOne(Main.java:596)
at com.android.dx.command.dexer.Main.processAllFiles(Main.java:498)
at com.android.dx.command.dexer.Main.runMonoDex(Main.java:264)
at com.android.dx.command.dexer.Main.run(Main.java:230)
at com.android.dx.command.dexer.Main.main(Main.java:199)
at com.android.dx.command.Main.main(Main.java:103)
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:483)
at SDKMain.main(SDKMain.java:129)
1 error; aborting
]
I already tried JAVA_OPT and JAVA_HOME solutions. But still couldn't solved
I ran into this using IntelliJ 13.1.4, JDK 1.6 but I would guess that this is caused by the same thing on any other IDE -> classes.jar is referenced/included more than once.
Check and make sure that the classes.jar you added to the project (from Unity\Editor\Data\PlaybackEngines\androidplayer\bin\classes.jar) isn't referenced/included more than once. If you go into File->Project Structure:
There should only be one "classes" under libraries.
There should be NO reference to classes under Artifacts (Artifacts is used to create the plugin .jar file.)
Check out this related answer ->
https://stackoverflow.com/a/8437996/3464367
My issue was actually related to having duplicate files. Well not really duplicates, but I had 2 adMob sdk packages (different versions), that were getting into conflict. After deleting the older one, everything was fixed. Are you using any 3rd party SDK's or something similar, if so, try removing them if possible and see if the issue persists. Try to find out which part of the code is causing this to happen. You could ultimately try to compile an empty project just for testing.
Today I solved similar problem of Error building Player: CommandInvokationFailure: Unable to convert classes into dex format. See the Console for details. with adding .jar file into Plugins\Android\
I got different kind of errors:
Caused by: com.android.dx.cf.iface.ParseException: bad class file magic (cafebabe) or version (0034.0000 ...
Caused by: com.android.dx.cf.iface.ParseException: class name (ht/stringing/test) does not match path (src/ht/stringing/test.class)
My result working solution was similar to this:
Code lives here:
verysimple\src\ht\stringing\test.java
I do:
> javac -classpath "c:\Android\sdk\platforms\android-15" ht\stringing\test.java
> jar cvf ..\dist\verysimple.jar ht\stringing\test.class
> copy ..\dist\verysimple.jar c:\ExUnityApp\Assets\Plugins\Android
Don't forget to compare your 'Minimum Api Level' in Player Setting. For me it was Android 4.0.3 ... (15)

Categories

Resources