Jetty 9.4 giving ArrayIndexOutOfBoundsException - java-8

I am trying to deploy my war file on jetty 9.4 ( tried both 9.4.0 and 9.4.8 with asm 5.1 and 6 respectively). I am getting below error. I am using java 1.8 for development
java.lang.RuntimeException: Error scanning entry org/aspectj/org/eclipse/jdt/internal/compiler/parser/UpdateParserFiles.class from jar file:///tmp/jetty-0.0.0.0-8080-xxxxx-service-8.0.0.0000-SNAPSHOT.war-_xxxx-8.0.0.0000-SNAPSHOT-any-4304648590162252598.dir/webapp/WEB-INF/lib/aspectjtools-1.8.13.jar
at org.eclipse.jetty.annotations.AnnotationParser.lambda$parseJar$0(AnnotationParser.java:883)
at java.util.TreeMap$ValueSpliterator.forEachRemaining(TreeMap.java:2893)
at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
at org.eclipse.jetty.annotations.AnnotationParser.parseJar(AnnotationParser.java:875)
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:839)
at org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call(AnnotationConfiguration.java:161)
at org.eclipse.jetty.annotations.AnnotationConfiguration$1.run(AnnotationConfiguration.java:468)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
at java.lang.Thread.run(Thread.java:745)
Caused by:
java.lang.ArrayIndexOutOfBoundsException: 3379
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:171)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:143)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:418)
at org.eclipse.jetty.annotations.AnnotationParser.scanClass(AnnotationParser.java:933)
at org.eclipse.jetty.annotations.AnnotationParser.parseJarEntry(AnnotationParser.java:918)
at org.eclipse.jetty.annotations.AnnotationParser.lambda$parseJar$0(AnnotationParser.java:879)
at java.util.TreeMap$ValueSpliterator.forEachRemaining(TreeMap.java:2893)
at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
at org.eclipse.jetty.annotations.AnnotationParser.parseJar(AnnotationParser.java:875)
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:839)
at org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call(AnnotationConfiguration.java:161)
at org.eclipse.jetty.annotations.AnnotationConfiguration$1.run(AnnotationConfiguration.java:468)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
at java.lang.Thread.run(Thread.java:745)​

The cause of that error is likely that you have too old of an ASM jar on the server side classpath.
I know you said you have already tried newer versions, but have you checked all the jars on your server classpath for all possible instances of ASM classes?
If you are using embedded-jetty, pay attention to your server Classpath, be 100% sure you don't have those ASM classes in multiple jars!
Also, under some configurations in embedded-jetty, the webapp's own WEB-INF/lib/*.jar could be used to scan the classes in that webapp. Which means an incompatible WEB-INF/lib/asm*.jar could be causing you problems.
For Java 1.8 bytecode and runtime, use ASM 5.1+
For Java 9 bytecode and runtime, use ASM 6+
The other issue is that you could have classes in that jar WEB-INF/lib/aspectjtools-1.8.13.jar which are for a bytecode that is higher then your runtime JVM (or ASM) can handle.
If you are working with JEP 238 (Multi-Release JAR spec) jars then this is more common, but I don't think aspectjtools-1.8.13.jar is one of those (note: haven't actually downloaded that jar and studied it)
See Eclipse Jetty Issue #1797 for more about JEP 238

Related

Module not found if graalpy is packaged in Spring Boot Jar

I'm building a Spring Boot (3 RC1) application with some Python code (GraalVM 22.3). Running the application in dev mode works. After building Jar with Maven I get an error:
Caused by: org.graalvm.polyglot.PolyglotException: ModuleNotFoundError: No module named 'pystac'
at org.graalvm.sdk/org.graalvm.polyglot.Context.eval(Context.java:399) ~[org.graalvm.sdk:na]
at ch.so.agi.sodata.stac.ConfigService.readXml(ConfigService.java:116) ~[classes!/:0.0.1-SNAPSHOT]
at ch.so.agi.sodata.stac.SodataStacApplication.lambda$init$0(SodataStacApplication.java:60) ~[classes!/:0.0.1-SNAPSHOT]
at org.springframework.boot.SpringApplication.callRunner(SpringApplication.java:767) ~[spring-boot-3.0.0-RC1.jar!/:3.0.0-RC1]
... 13 common frames omitted
The python.Executable shows to the graalpy executable packaged in the Jar: file:/Users/stefan/sources/datenbezug/sodata-stac/target/sodata-stac-0.0.1-SNAPSHOT.jar!/BOOT-INF/classes!/venv/bin/graalpy
Grepping the Jar shows the pystac module in the Jar file, e.g. BOOT-INF/classes/venv/lib/python3.8/site-packages/pystac/item.py
Creating the context with:
var VENV_EXECUTABLE = ConfigService.class.getClassLoader()
.getResource(Paths.get("venv", "bin", "graalpy").toString())
.getPath();
var context = Context.newBuilder("python")
.allowAllAccess(true)
.option("python.Executable", VENV_EXECUTABLE)
.option("python.ForceImportSite", "true")
.build()
Is it possible to put the whole python stuff including third party libs into the FatJar? Or did I just miss some packaging magic?
The issue is that the default Truffle filesystem, AFAIK, only supports the actual filesystem of your OS, i.e., it does not "see" resources in the jar file. This is why it works in dev mode when the resources are just files on the filesystem.
There are two options how to deal with this:
do not put the venv into resources, but deploy it separately, such that it ends up somewhere on the filesystem
implement custom Truffle filesystem, but I am not aware of anyone who tried this with virtual environments yet, so there may be some rough edges. Most notably GraalVM LLVM Toolchain that is used to build Python native extensions for execution with GraalVM LLVM engine produces system specific binaries, so your jar will not be as portable as one would expect from a jar. If you only use pure Python packages, it may be fine.

SonarQube doesn't work with Intellij Community 2019.2

I'm using SonarLint 4.1.1.3345 with IntelliJ Community 2019.2 version by binding project to our SonarQube (with SonarJava 5.3 (build 13828)installed) server. However, I got error with below stack trace from SonarLint log:
Java Main Files AST scan
60 source files to be analyzed
Unable to create symbol table for : C:\Users\username\SomeFile.java
java.lang.IllegalArgumentException: Unsupported class file major version 55
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:166)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:148)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:136)
at org.sonar.java.resolve.BytecodeCompleter.loadClass(BytecodeCompleter.java:204)
at org.sonar.java.resolve.Symbols.<init>(Symbols.java:176)
at org.sonar.java.resolve.SemanticModel.createFor(SemanticModel.java:59)
at org.sonar.java.model.VisitorsBridge.visitFile(VisitorsBridge.java:110)
at org.sonar.java.ast.JavaAstScanner.simpleScan(JavaAstScanner.java:96)
at org.sonar.java.ast.JavaAstScanner.scan(JavaAstScanner.java:68)
at org.sonar.java.JavaSquid.scanSources(JavaSquid.java:116)
at org.sonar.java.JavaSquid.scan(JavaSquid.java:110)
at org.sonar.plugins.java.JavaSquidSensor.execute(JavaSquidSensor.java:93)
at org.sonarsource.sonarlint.core.analyzer.sensor.SensorsExecutor.executeSensor(SensorsExecutor.java:81)
at org.sonarsource.sonarlint.core.analyzer.sensor.SensorsExecutor.execute(SensorsExecutor.java:72)
at org.sonarsource.sonarlint.core.container.analysis.AnalysisContainer.doAfterStart(AnalysisContainer.java:132)
at org.sonarsource.sonarlint.core.container.ComponentContainer.startComponents(ComponentContainer.java:125)
at org.sonarsource.sonarlint.core.container.ComponentContainer.execute(ComponentContainer.java:110)
at org.sonarsource.sonarlint.core.container.storage.StorageAnalyzer.analyze(StorageAnalyzer.java:75)
at org.sonarsource.sonarlint.core.container.storage.StorageContainerHandler.analyze(StorageContainerHandler.java:82)
at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.lambda$analyze$0(ConnectedSonarLintEngineImpl.java:152)
at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.withReadLock(ConnectedSonarLintEngineImpl.java:344)
at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.withReadLock(ConnectedSonarLintEngineImpl.java:334)
at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.analyze(ConnectedSonarLintEngineImpl.java:149)
at org.sonarlint.intellij.core.ConnectedSonarLintFacade.analyze(ConnectedSonarLintFacade.java:74)
at org.sonarlint.intellij.core.SonarLintFacade.startAnalysis(SonarLintFacade.java:63)
at org.sonarlint.intellij.analysis.SonarLintAnalyzer.analyzeModule(SonarLintAnalyzer.java:97)
at org.sonarlint.intellij.analysis.SonarLintTask.analyze(SonarLintTask.java:176)
at org.sonarlint.intellij.analysis.SonarLintTask.run(SonarLintTask.java:100)
at org.sonarlint.intellij.analysis.SonarLintUserTask.run(SonarLintUserTask.java:39)
at org.sonarlint.intellij.analysis.SonarLintJobManager.lambda$runTask$1(SonarLintJobManager.java:120)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:169)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:591)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:537)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:59)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:156)
at org.sonarlint.intellij.analysis.SonarLintJobManager.lambda$runTask$2(SonarLintJobManager.java:120)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
"Unsupported class file major version 55" tells me that the class file Sonar used for code analysis is for java 11 version whereas my class was compiled with java 7 (I took the same class and ran it with javap it showed major version 51), and I don't even have java 11 installed on my system.
Because it works for my teammates. The only difference is they have lower version of IntelliJ installed. So I downloaded IntelliJ 2019.1.4 and it started working.
Could someone explain why it doesn't work with later version of IntelliJ and why the above error occurred? Thanks in advance!
This is a known limitation about classloaders in the IDE/sonarlint/plugin:
https://community.sonarsource.com/t/sonarlint-analysis-fails-on-intellij-2019-2-with-java-11-runtime/12905/3
https://jira.sonarsource.com/browse/SONARJAVA-3056
Example with SonarLint
In SonarLint IntelliJ running environment, this is more or less the
classpath hierarchy:
JDK -> IntelliJ classes -> SonarLint (+deps) [child-first] -> Java
plugin (+packaged deps) [child-first] -> Squid [parent-first]. So
imagine we analyze a class that is using a class X. If IntelliJ's
classloader happens to also use class X (same fully qualified name),
this will be used instead of the X provided in the analysis classpath,
even if they are to different copies of the class (different versions,
for example).

Neo4j-Ogm with Spring Boot: Classpath scanning doesn't find DomainEntities when deployed as runnable jar

I am in the process of migrating an existing app from Spring-Data-Neo4j 3.x to 4.1 using neo4j-ogm 2.0.4.
After overcoming some obstacles, it is now running fine when launched directly from IDE.
However it doesn't find any DomainEntities when I run it via a Spring Boot runnable jar:
(ClassPathScanner.java:132) Classpath elements:
(ClassPathScanner.java:134) D:\Programme\Project\myProject.jar
(DomainInfo.java:108) Starting Post-processing phase
(DomainInfo.java:74) Building annotation class map
(DomainInfo.java:87) Building interface class map for 0 classes
(DomainInfo.java:136) Checking for #Transient classes....
(DomainInfo.java:155) Registering converters and deregistering transient fields and methods....
(DomainInfo.java:159) Post-processing complete
(DomainInfo.java:69) 0 classes loaded in 40179 milliseconds
The executable jar is built using the Spring Boot Gradle Plugin which allows to make a jar executable:
springBoot {
executable = true
}
I've attached to the app via remote debugging when the jar starts and found that org.neo4j.ogm.scanner.ClassPathScanner#scan only contains my jar as classPathElement. According to the code, this should now be scanned as a zip/jar file. When classPathElement.isFile() is executed however, this evaluates to false and the jar is skipped.
Why is that the case? Is an executable jar not a file?
What steps can I take to get this running? I could probably use some other deployment mechanism, but I found this fairly simple and well working.
I did some additional investigation and it turned out that this was not related to the runnable jar at all. This was actually caused by having a space in the path to the jar file.
I think that is a perfectly valid case and am not sure why this doesn't work. In my case it was ok though to simply rename the respective folder and remove the space.

java.lang.NoSuchMethodError: org/springframework/beans/MutablePropertyValues.add(Ljava/lang/String;Ljava/lang/Object;)

While deploying application on weblogic 11g I get following error.
java.lang.NoSuchMethodError: org/springframework/beans/MutablePropertyValues.add(Ljava/lang/String;Ljava/lang/Object;)Lorg/springframework/beans/MutablePropertyValues;
I have following spring jars in my application
com.springsource.org.aopalliance-1.0.0.jar
com.springsource.org.aopalliance-sources-1.0.0.jar
org.springframework.beans-3.2.1.RELEASE.jar
org.springframework.context-3.2.1.RELEASE.jar
org.springframework.core-3.2.1.RELEASE.jar
org.springframework.expression-3.2.1.RELEASE.jar
org.springframework.jdbc-3.2.1.RELEASE.jar
org.springframework.transaction-3.2.1.RELEASE.jar
org.springframework.web.servlet-3.2.1.RELEASE.jar
org.springframework.web-3.2.1.RELEASE.jar
spring-aop-3.2.1.RELEASE.jar
And I have following other jars as well
commons-beanutils.jar,
commons-collections.jar,
commons-dbcp-1.4.jar,
commons-digester.jar,
commons-io-1.1.jar,
dom4j-1.3.jar,
jackson-core-asl-1.4.2.jar,
jackson-mapper-asl-1.4.2.jar,
jcommon-1.0.16.jar,
jfreechart-1.0.13.jar,
jstl-1.2.jar,
ojdbc6-11.2.0.3.jar,
slf4j.api-1.6.1.jar,
slf4j-nop-1.6.1.jar,
log4j-1.2.17.jar ,
Please help
You obviously have another version of this class in classpath. Do you have spring-beans in system classloader?
As Oracle documentation says, WebLogic web deployment descriptor weblogic.xml has a special element prefer-web-inf-classes.
By setting this element to true, you are changing classloader policy such that classes from application are loaded in preference to system classloader classes.

JDOM + Jaxen + Websphere 7 = java.lang.NoClassDefFoundError: org.jaxen.BaseXPath

I would like to use JDOM in a Webapp project. This works just fine. But now I want to add some stuff using XPath, but if I try to work with an XPath, I just get an exception:
com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0068E: Uncaught exception created in one of the service methods of the servlet MyServlet in application MyProjectEAR. Exception created : java.lang.NoClassDefFoundError: org.jaxen.BaseXPath
at java.lang.J9VMInternals.verifyImpl(Native Method)
at java.lang.J9VMInternals.verify(J9VMInternals.java:72)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:134)
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:136)
at org.jdom.xpath.XPath.newInstance(XPath.java:126)
at org.jdom.xpath.XPath.selectNodes(XPath.java:337)
[..]
Caused by: java.lang.ClassNotFoundException: org.jaxen.BaseXPath
at java.net.URLClassLoader.findClass(URLClassLoader.java:421)
at com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader.java:150)
at java.lang.ClassLoader.loadClass(ClassLoader.java:652)
at com.ibm.ws.bootstrap.ExtClassLoader.loadClass(ExtClassLoader.java:90)
at java.lang.ClassLoader.loadClass(ClassLoader.java:618)
at com.ibm.ws.classloader.ProtectionClassLoader.loadClass(ProtectionClassLoader.java:62)
at com.ibm.ws.classloader.ProtectionClassLoader.loadClass(ProtectionClassLoader.java:58)
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:540)
at java.lang.ClassLoader.loadClass(ClassLoader.java:618)
... 35 more
The jaxen.jar is in my classpath, and the org.jaxen.BaseXPath class is there just fine. Why is Websphere not finding it? It works with all the other libraries I have there. When googling I found this, where someone says that he has a conflicting version somewhere and I should make sure that jars from my web app directory have precedence. In eclise' Built Path Configuration I set Web App Libraries above the WebSphere library (only the src dir is now above the web app libs), but that did not change anything. Unfortunatelly I did not really understand the part about the EAR which seems important...?
Update: In the meantime this gave me a new clue. I found on WebSphere's Administration Console the classpath and a list with all jars that are considered by the class loaders. These are quite a number and I searched them with a little grep and unzip -l magic and figured that the file /opt/ibm/WebSphere/PortalServer/wcm/prereq.wcm/wcm/shared/app/jdom.jar contains jdom (without the jaxen stuff). So maybe this jdom jar is loaded, but jaxen in an incompatible version is loaded from my lib directory?
Additionally I found in WebSphere's Administration Console the "parent first/last" setting for my application, but everything is grayed out! I can't switch to parent last :-(.
What can I do to find and fix the problem?

Resources