Apache CXF auto-discovery feature configuration error [duplicate] - java

My web application runs fine on JDK 1.7 but crashes on 1.8 with the following exception (during application server startup with Jetty 8). I am using Spring version: 3.2.5.RELEASE.
Exception:
org.springframework.core.NestedIOException: ASM ClassReader failed to parse class file - probably due to a new Java class file version that isn't supported yet
I assume that problem occurs because of spring and "asm.jar" library on which it depends.
How do I resolve this?

As #prunge and #Pablo Lozano stated, you need Spring 4 if you want compile code to Java 8 (--target 1.8), but you can still run apps on Java 8 compiled to Java 7 if you run on Spring 3.2.X.
Check out
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/new-in-4.0.html
Note that the Java 8 bytecode level (-target 1.8, as required by -source 1.8) is only fully supported as of Spring Framework 4.0. In particular, Spring 3.2 based applications need to be compiled with a maximum of Java 7 as the target, even if they happen to be deployed onto a Java 8 runtime. Please upgrade to Spring 4 for Java 8 based applications.

If you encounter this error even if you compile with -target 1.7, please note that this is because of a bug in Spring Framework which causes ASM classreader to load jdk classes (java.* or javax.*), which are, of course, compiled with -target 1.8.
This, combined with the old ASM version in spring 3.2.8 and below, which does not support parsing of 1.8 class files, can also lead to this error.
More info about the issue can be found here: https://jira.spring.io/browse/SPR-11719
This should be fixed in Spring Framework version 3.2.9, which is due to be released soon.
Of course, upgrading to Spring Framework 4 will also resolve the issue, as it already contains a newer version of ASM.
However, if for some reason you can't upgrade to version 4 yet, it's good to know there's an alternative (soon).

I had the same problem and solved it. I am using spring 3.x with java 8. If above solutions are not working change the jars and search whether those jars are compatible with the java version you are using or not. spring 3.x is not compatible with java 8.

I had the same problem,
1.Go to:
maven -> executive maven goal -> mvn clean
It helps :)
2.Invalid caches..

This problem might because of wrong selection of environments. I tried changing JRE to Java SE 1.8 which is the Java version installed.
Project>>Right click>>Properties>>Java Build Path>>Libraries>>Double click JRE system Library>>Execution Environment to JAVA VERSION INSTALLED.

if you use java 8 or next version you need to upgrade spring version and spring version should be 4.xxx

Spring 4 can be used for java 8 to resolve this issue. I just tested it and it works.
This issue is fixed since Spring 3.2.9-RELEASE version.

Related

Does Grails 3.x support Java 11

I know Java 11 has not been officially released yet, but has anyone tested Grails 3.x with an early access release of Java 11? Or does anyone know when or if Grails 3.x will support Java 11?
Well I know that the support for Java 9+ in Groovy is getting worked on and I think 2.5.2 had some fixes. Technically Groovy will work on newer versions of java, but you'll get a bunch of warnings. All of this is supposed to be worked out for Groovy 3.0, probably coming around the end of the year, based on what I hear at GR8Con.US.
All that being said, Grails 3.3 is on Groovy 2.4.x, with spring boot 1.2, which I don't think either support newer versions of Java. Grails 4 is supposed to be coming out by the end of the year, with Groovy 2.5, and a newer version of spring boot. Once Groovy 3 comes out it shouldn't be too long before Grails upgrades to it.
Also check out the Groovy Podcast, there was a metion on the support from Groovy:
https://youtu.be/XQLblr2OGJ8
I know Java 11 has not been officially released yet, but has anyone
tested Grails 3.x with an early access release of Java 11?
I tried using Grails 3.3.8 and the early access release of JDK 11 and it didn't work, but I wondered if that might be something to do with the JDK.
Then I tried again using Oracle's official release of JDK 11 which came out a couple of days ago. I rebuilt an existing Grails project in NetBeans 9.0 using JDK 11 / Grails 3.3.8, and got the following error:
Command [clean] error: Could not determine java version from '11'. (Use --stacktrace to see the full trace)
I get similar errors when using JDK 9 and 10, but the project builds and runs fine using JDK 8.
See this SO answer for a similar problem when using Grails with JDK 10: Could not determine java version from '10.0.2' while starting Grails 3.3.8 application:
Grails 3.3.8 does not support Java 10. You will have to use Java 7 or Java 8 if you want to use Grails 3.3.8.
Or does anyone know when or if Grails 3.x will support Java 11?
Grails 3.x won't ever support JDK 11 according to a Grails developer. See the comments for the SO answer I linked to above:
You have to wait for Grails 4 to use a JDK > 8.
I don't know anything about a proposed release date for Grails 4.
Java 11 is supported in Grails 4. However, note Grails 4 still builds on Groovy 2.5.x which doesn't run all that smooth on Java 9-11 compared to Groovy 3. So warnings and stuff like that is to be expected.
//EDIT 22/01/2022: Grails 5 is build is built on Groovy 3.0.x and therefore works smoothly with Java 11.

How do I support an application built using Java 1.8 in Java 9?

We have a standalone application built using Java 1.8 and when I test running that application using Java 9, I get a NoClassDefError exception on the javax.xml.soap.SoapException class. I have read enough to know that Java 9 now has the module concept... and that if I add the "--add-modules java.se.ee" option on my 'java' call in the startup script for the application, it then runs correctly.
My question is... how do I still support this application running against a 1.8 JRE? I can't just put the --add-modules option in the startup script since that causes an error when attempting to run against the 1.8 JRE. I really don't want to have to put logic in the startup script to try to determine which version of JRE the user is running and optionally put the new --add-modules option in there.
Any suggestions? Thanks in advance!
You should include java9 specific information 'module-info.java' into your application, so it will not require the command line option. See e.g. here: How to add a Java 9 module via manifest.mf?
The web services module (java.xml.ws, which includes SAAJ) has been deprecated in Java SE 9 with a view to removing it from Java SE and the JDK in the future. The first step on that road to removing it is to not resolve it by default. It is "as if" the module does not exist and this is why you get a CNFE when you run it on JDK 9.
Yes, you can workaround around it temporarily with --add-modules=java.xml.ws (more precise than --add-modules=java.se.ee) and you should be able to get your script to pick this up using the JDK_JAVA_OPTIONS env variable (see http://jdk.java.net/9/release-notes#JDK-8170832) which is new in JDK 9 and so will be ignored in JDK 8.
The alternatives (and the JDK 9 Migration Guide will have more on this) is to move to the standalone version of JAX-WS and SAAJ. These APIs have standalone versions that update at a different pace to Java SE and the JDK. You should find the latest (2.3.0) in Maven for example. The standard versions can be deployed on the class path, and in the future as modules in the event that you migrate your application to modules in the future.
Please take a look at this article. This gives the ways to solve the compatibility concern that you have raised.
https://dzone.com/articles/the-legacy-developers-guide-to-java-9
Please include module-info.java file in your application. Java 9 will consider the same and will be ignored by Java 8.

Fast-ClassPath-Scanner does not work with java 6 runtime?

Fast-ClassPath-Scanner
https://github.com/lukehutch/fast-classpath-scanner using latest version.
On executing(get names of all classes in war which includes all jars and classes)
new FastClasspathScanner(basePackage).scan().getNamesOfAllClasses()
getting:
unsupportedclassversion error with jre 6
Please provide a solution to it or alternative to perform same.
FastClasspathScanner is compiled for java 1.7
When you try to load it in a 1.6 (JRE6) environment it fails with an UnsupportedClassVersionError. This error indicates that the class version (here 1.7) is not compatible with the JVM version (here 1.6).
Java 7 is not backwards compatible with Java 6. You could try to build the FastClasspathScanner library yourself unter 1.6 (not sure if that's possible). Or upgrade your project to Java 7.
Correct, I am the author of FastClasspathScanner, and it's not a goal to get this working with JRE6. However, patches for supporting 1.6 are welcome.

Unsupported classversion when deploying to jboss

I am trying to add jersey to our (old) jboss project but I get "Unsupported classversion" when deploying to jboss - which points to a compile vs runtime version mismatch. In production and on our test servers, the application runs on java 6 but it is built using java 7. Corporate bureaucracy means that it will take months to upgrade the servers to java 7 but the code itself no longer compiles in java 6 due to some javaws dependencies. So for the foreseeable future, I am stuck with these versions.
All my changes work fine if they are compiled and run in java 7 but don't deploy if compiled in java 7 but run in java 6.
I have tried using the maven-compiler-plugin to force the target to be 1.6 but then I run into "source release 1.7 requires target release 1.7" errors.
I can see that at least one the jersey jar artifacts that is downloaded by maven is compiled with java 7 (51.0) and that presumably is the cause. Anyone have any tips as to how I can go forward with this?
Indeed, Downgrading the version of jersey to one compiled with java6 sorted the issue (kinda - I get some jersey problems now instead).
I extracted the class files from the .jar and ran "file" on one and I found that 2.6 version of jersey was the last to support java 6

Java 1.8 ASM ClassReader failed to parse class file - probably due to a new Java class file version that isn't supported yet

My web application runs fine on JDK 1.7 but crashes on 1.8 with the following exception (during application server startup with Jetty 8). I am using Spring version: 3.2.5.RELEASE.
Exception:
org.springframework.core.NestedIOException: ASM ClassReader failed to parse class file - probably due to a new Java class file version that isn't supported yet
I assume that problem occurs because of spring and "asm.jar" library on which it depends.
How do I resolve this?
As #prunge and #Pablo Lozano stated, you need Spring 4 if you want compile code to Java 8 (--target 1.8), but you can still run apps on Java 8 compiled to Java 7 if you run on Spring 3.2.X.
Check out
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/new-in-4.0.html
Note that the Java 8 bytecode level (-target 1.8, as required by -source 1.8) is only fully supported as of Spring Framework 4.0. In particular, Spring 3.2 based applications need to be compiled with a maximum of Java 7 as the target, even if they happen to be deployed onto a Java 8 runtime. Please upgrade to Spring 4 for Java 8 based applications.
If you encounter this error even if you compile with -target 1.7, please note that this is because of a bug in Spring Framework which causes ASM classreader to load jdk classes (java.* or javax.*), which are, of course, compiled with -target 1.8.
This, combined with the old ASM version in spring 3.2.8 and below, which does not support parsing of 1.8 class files, can also lead to this error.
More info about the issue can be found here: https://jira.spring.io/browse/SPR-11719
This should be fixed in Spring Framework version 3.2.9, which is due to be released soon.
Of course, upgrading to Spring Framework 4 will also resolve the issue, as it already contains a newer version of ASM.
However, if for some reason you can't upgrade to version 4 yet, it's good to know there's an alternative (soon).
I had the same problem and solved it. I am using spring 3.x with java 8. If above solutions are not working change the jars and search whether those jars are compatible with the java version you are using or not. spring 3.x is not compatible with java 8.
I had the same problem,
1.Go to:
maven -> executive maven goal -> mvn clean
It helps :)
2.Invalid caches..
This problem might because of wrong selection of environments. I tried changing JRE to Java SE 1.8 which is the Java version installed.
Project>>Right click>>Properties>>Java Build Path>>Libraries>>Double click JRE system Library>>Execution Environment to JAVA VERSION INSTALLED.
if you use java 8 or next version you need to upgrade spring version and spring version should be 4.xxx
Spring 4 can be used for java 8 to resolve this issue. I just tested it and it works.
This issue is fixed since Spring 3.2.9-RELEASE version.

Categories