I have created an app(spring boot 1.5.6) using start.spring.io and trying to deploy it to Weblogic 12.1.3.0.0.
Messages in administration console:
Error Unable to access the selected application.
Error java.io.IOException
Error weblogic.utils.compiler.ToolFailureException
Message in logs:
<23.08.2017 13:40:26 GMT+03:00> <Error> <J2EE> <BEA-160228> <AppMerge failed to merge your application. If you are running AppMerge on the command-line, merge again with the -verbose option for more details. See the error message(s) below.>
These links don't help:
https://docs.spring.io/spring-boot/docs/1.5.x/reference/html/howto-traditional-deployment.html
Deploy Spring Boot app in Weblogic
Update:
The problem is dependency JAX-RS. Without it app is deployed successfully. Not sure how to make it work With this dependency
Update x2:
Removed Jax-rs and now:
java.lang.NoSuchMethodError:org.springframework.core.annotation.AnnotationAwareOrderComparator.sort(Ljava/util/List;)V
Resolved by this
Our team started to use Spring Boot 2.0.0 and we had this issue also.
After some investigation, we have found that AppMerge tool scans all classes before deploy.
Root cause:
In case of WebLogic 12.1.3.* it fails because of Multi-Release JAR Files.
AppMerge tool can't work with JDK 9 files.
Solution:
Use Log4j 2.8.2
In pom.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.0.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
...
<properties>
...
<log4j2.version>2.8.2</log4j2.version>
...
</properties>
...
</project>
I had this problem, and the answer by Artyom is correct, but I'll provide an answer to give some more details.
The problem in my case was Lombok. Any version after 1.6.20 (I believe) added Java 9 Module support. This adds a module-info.class in the root of the .jar file. I confirmed this was the problem by removing the module-info.class file from the jar and rebuilding my war. Appmerge was able to run successfully with this file removed. I would not suggest doing this in production, I just did it to confirm the problem. Not sure why Appmerge does not like module-info.class files.
Some advice that can help you troubleshoot this problem:
A simple method to identify the problematic dependency is to take a known project that works, then add dependencies from the failing project until the good project fails.
Extract the jar file for the broken dependency and look for a module-info.class file in the root directory. If it's there, this is likely the problem.
A useful command for testing if the .war merges: java -cp c:\path_to_weblogic_server\wlserver\server\lib\weblogic.jar weblogic.appmerge -verbose target/your_war_file.war. This will save you time trying to deploy in the console.
As for a solution for fixing the dependency besides reverting to an older version, I'm still trying to figure out.
Note: In the case of Lombok, I believe your supposed to set the scope to provided, which I wasn't doing in my case. The .jar won't be included when the scope is provided so you won't run into this problem. See this answer for more info.
Spring boot 2.0 relies on JPA 2.1 while Weblogic 12.1.3 vanilla installation relies on JPA 1.0.
Take note that Weblogc 12.1.3 is kind of particular, it is split between two java enterprise specifications 6 and 7.
You will need to upgrade your JPA api and add the hibernate 5 implementation to your weblogic 12.1.3 instance.
In you web app, make sure what dependencies you have and that they do not overlap with the ones already provisioned under Weblogic classloader.
I have mentioned the full description of steps here:
http://javagoogleappspot.blogspot.com/2018/05/make-your-spring-boot-20-compatible.html
After trying Arytom's solution without any luck, we tried investigating joshaidan's suggestion. Upon further digging we found the Oracle support document: 2645919.1
From that article:
Cause
Application package contains incompatible jar library / class. WebLogic internally uses ASM library to check class bytecode version, it has following similar code to check bytecode version is compatible, or IllegalArgumentException will be thrown.
https://github.com/llbit/ow2-asm/blob/master/src/org/objectweb/asm/ClassReader.java
166 public ClassReader(final byte[] b, final int off, final int len) {
167 this.b = b;
168 // checks the class version
169 if (readShort(off + 6) > Opcodes.V1_8) {
170 throw new IllegalArgumentException();
171 }
Update class file version to 53.0
When generating class files in conjunction with -target 9 (specified either explicitly or implicitly), javac will generate class files with a major version number of 53. For details of version 53 class files, see the Java Virtual Machine Specification.
The JDK classes themselves mostly use version 53 class files.
Tools or libraries that rely on ASM or other bytecode manipulation libraries may need updated versions of these libraries to work with version 53 class files.
Solution
Replace the issue class/ library with compatible release.
[oracle#sandbox ~]$ cd ~/war
[oracle#sandbox war]$ for i in `find . -name '*.jar'`; do unzip -qo $i -d $i.delemete; done
[oracle#sandbox war]$ find . -name \*.class | xargs file | sort -t, -k2 | tail -n 10
./WEB-INF/js.jar.delemete/examples/webservices/jaxws/InvokeTransactionResponse.class: compiled Java class data, version 52.0 (Java 1.8)
./WEB-INF/js.jar.delemete/examples/webservices/jaxws/MyClient$1.class: compiled Java class data, version 52.0 (Java 1.8)
./WEB-INF/js.jar.delemete/examples/webservices/jaxws/MyClient.class compiled Java class data, version 52.0 (Java 1.8)
./WEB-INF/js.jar.delemete/examples/webservices/jaxws/ObjectFactory.class: compiled Java class data, version 52.0 (Java 1.8)
./WEB-INF/js.jar.delemete/examples/webservices/jaxws/package-info.class: compiled Java class data, version 52.0 (Java 1.8)
./WEB-INF/js.jar.delemete/examples/webservices/jaxws/SimpleClientJwsImpl.class compiled Java class data, version 52.0 (Java 1.8)
./WEB-INF/js.jar.delemete/examples/webservices/jaxws/SimpleClientService.class: compiled Java class data, version 52.0 (Java 1.8)
./WEB-INF/lib/jackson-annotations-2.10.2.jar.delemete/module-info.class compiled Java class data, version 53.0
./WEB-INF/lib/jackson-core-2.10.2.jar.delemete/module-info.class: compiled Java class data, version 53.0
./WEB-INF/lib/jackson-databind-2.10.2.jar.delemete/module-info.class: compiled Java class data, version 53.0
The thing to note in the above example is that the last 3 lines are class files with version 53.0, which are going to be the offending classes.
Upon investigation of our app, using Spring boot 1.5.6.RELEASE we found that the Jersey dependency was pulling in asm-all-repackaged:2.5.0-b32 which is compiled for JDK9. Adding the following explicit dependency addressed the issue, the solution to which was found here: https://github.com/jersey/jersey/issues/3617
<!--
Work around bug where Jersey pulls in asm-all-repackaged:2.5.0-b32, which is compiled for JDK9. This prevents deployment to WebLogic 12.1.3 on JDK8
https://github.com/jersey/jersey/issues/3617
Oracle Support Doc ID 2645919.1
-->
<dependency>
<groupId>org.glassfish.hk2.external</groupId>
<artifactId>asm-all-repackaged</artifactId>
<version>2.4.0</version>
</dependency>
Try to remove dependency of tomcat:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
I faced same issue, and my solution is deleting weblogic.xml file in project folder.
I shared for whom concerned.
Related
I have upgraded to neo4j 4.3.2 community version. This brings in other neo4J packages like neo4j-graph-api, neo4j-logging, neo4j-procedure-api,neo4j-resource all 4.3.2. However it throw compilation error for neo4j-garph-api related classes. Error thrown is:
\org.neo4j\neo4j-graphdb-api\4.3.2\5c61e5a720893ca4a114c92aa7f256375e87edf5\neo4j-graphdb-api-
4.3.2.jar(org/neo4j/graphdb/Label.class)
class file has wrong version 55.0, should be 52.0
Please remove or make sure it appears in the correct subdirectory of the classpath.
Similar error are thrown for classes from neo4j-logging 4.3.2 and neo4j-procedure-api 4.3.2, neo4j-resource 4.3.2 etc
Downgrading these packages individually works. I would assume as all these sub-packages also have their own 4.3.2 version, that should make it compatible with the latest neo4j version.
What is going wrong? Have I missed something here?
Partial Dependency tree
I found the issue. The main problem was 'class file has wrong version 55.0, should be 52.0'. This is caused when the Jar that I have included in the project was compiled with Java 11. The person who compiled that Jar could have used Java 11 only features and hence had to generate the bytecode that is only compatible with JDK 11 or higher.
My IDE was using java 8. When I changed my IDE to use Java 11, it compiled the project.
I am using openjdk11, getting below error while building using maven.
Below is the error i am getting in logs :
Caused by: org.apache.maven.plugin.PluginContainerException: An API incompatibility was encountered while executing org.jvnet.jaxb1.maven2:maven-jaxb1-plugin:1.0-rc10:generate: java.lang.NoSuchMethodError
I have created my own openjdk11 rpm, i think i am missing to include some files in the rpm i am not sure about
How do i fix it ?
Developers on JDK 9+ can deploy standalone versions of the Java EE and CORBA technologies on the class path or use the --add-modules flag on the command line to resolve the modules in the JDK runtime image.
If you wish to compile or run applications on the latest JDK can find and deploy alternate versions of the Java EE technologies.
Add third-party dependencies that contain the classes you need. The easiest way to do that is to stick to the reference implementations (given as Maven coordinates without version – use the most current ones):
JAF: with com.sun.activation:javax.activation
CORBA: there is currently no artifact for this
JTA: javax.transaction:javax.transaction-api
JAXB: com.sun.xml.bind:jaxb-impl
JAX-WS: com.sun.xml.ws:jaxws-ri
Commons Annotation: javax.annotation:javax.annotation-api
I'm trying out Travis CI with a Java project (pretty standard Maven, Spring setup).
Based on Travis docs, this should suffice in the .travis.yml file:
language: java
Travis should notice the project's pom.xml and run mvn test by default.
However, the Travis build fails, giving me:
error: static import declarations are not supported in -source 1.3
My sources are Java 1.6. How and where should I tell that to Travis? The Java project docs don't mention -source option at all. (Also, 1.3 is a bit strange default, isn't it?)
Got it working by customising install and script in .travis.yml like this:
language: java
install: mvn install -Dmaven.compiler.target=1.6 -Dmaven.compiler.source=1.6 -DskipTests=true
script: mvn test -Dmaven.compiler.target=1.6 -Dmaven.compiler.source=1.6
...as suggested in this answer.
Anyway, I don't know where exactly the Java 1.3 default comes from, but IMHO that should be fixed. Travis documentation talks of "reasonably good defaults", but in this case that doesn't seem to be true.
Another option would be to add a lengthy piece of Maven XML to explicitly specify the source & target levels. Well, personally I'm opposed to the idea of having to do that, just because a CI environment has silly defaults. (Isn't the whole point with Maven to avoid explicitly specifying stuff by using reasonable conventions?) With my current pom.xml everything works fine locally (e.g. mvn test) as well as when deploying on Heroku.
Update (2015, Java 8)
Just wanted to add that as of 2015, with a Java 8 codebase, you no longer need such customisations in Maven or Travis config. You get away with the following:
In pom.xml, under top-level <project>:
<properties>
<java.version>1.8</java.version>
</properties>
And in .travis.yml:
language: java
jdk: oraclejdk8
Which is nice. Note that JDK 8 must be specified, even when pom.xml sets Java version to 1.8. Travis otherwise defaults to JDK 7.
This is because you do not explicit set the source and target levels in your maven-compiler-plugin configuration in your pom.xml.
Older versions of Maven then use the javac default which is Java 1.3 in OpenJDK (as opposed to 1.5 in Oracle Java).
This problem is certainly related to a Bug in Maven3 Ubuntu package, which is currently installed on Travis worker machines.
Good News: In next Travis CI build environment, Maven 3.1.1 will be installed with Apache tarball release. This update is planned to be deployed in November 2013...
Created a web app using maven and deployed it on heroku. Everything works find but when I call a action that uses the postgresql-9.2-1002.jdbc4 driver I get:
java.lang.UnsupportedClassVersionError: org/postgresql/Driver : Unsupported major.minor version 51.0 (unable to load class org.postgresql.Driver)
I know that the problem is I'm using jdk 7 on my development environment and a lower version is running on heroku (at least I think so). My first question is, why does the other actions don't give this error only actions that uses postqresql driver gives this problem the rest of the app works just fine? The other thing I did was download jdk 6 and then added it to my project build path, then configure eclipse compiler compliance to 1.6 but even then I have the same problem. How can I solve this?
For java 6 use:
postgresql-9.2-1004-jdbc4.jar
postgresql-9.3-1100-jdbc4.jar
For java 7 use:
postgresql-9.2-1004-jdbc41.jar
postgresql-9.3-1100-jdbc41.jar
The solution is to use a copy of the database driver that is compiled for JDK 6.
It seems that you are not getting the problem with your application code because your build changes worked. (Specifically the change to the compliance level. I don't think adding a JDK to the (regular) build path will make any difference.)
But of course, that won't make any difference for the database driver ... because you are not compiling that.
However, according to the download page, postgresql-9.2-1002.jdbc4 is supposed to be compatible with Java 6 as well as 7. So maybe you've gotten the JAR from somewhere else ... or by compiling from source with a Java 7 target.
UPDATE - I can confirm that the JAR on the download site has a Driver class whose bytecode version is 50.0 not 51.0. I suggest you download and use a fresh copy from there.
If you are using maven, the 9.2-1002-jdbc4 version on central repository has been compiled using 1.7 target. Use previous version until it has been fixed.
It seems that this has been resolved with the latest build ID 1003:
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>9.2-1003-jdbc4</version>
</dependency>
Best way is to Install Higher Version of java that your Application Compile with and suppose if i have Application with compile with Jre 1.6 then i need 1.6 or Higher Version of Jre 1.6 and ya one thing is that
or
Just Compile your Class file i mean your application.java file with Default Jre that you have Available with java and Just Run on the same.
or Third Option.
Download that JRE and install that JRE version in your Machine.
I have encountered this problem and also the ClassNotFoundException for loading JDBC driver problem. The solution is to get the correct version of the postgres jar from http://jdbc.postgresql.org/download.html#jdbcselection. If you are using Maven, add the version of your dependency accordingly.
The alternative to swapping out your Java 6-incompatible Postgres driver for an alternative Java 7-friendly version (as recommended by most of the other answers) is to have Heroku use Java 7 to compile and run your application. If you're using JDK 7 for development, as you say, this might help avoid other incompatibilities.
To do this, follow these instructions on Heroku Devcenter. Here's a summary:
Create a file named system.properties in your app's base directory.
Add the property java.runtime.version=1.7 to the file, i.e.:
java.runtime.version=1.7
Commit the system.properties file and push to Heroku.
Had the same issue
On this page - http://jdbc.postgresql.org/download.html
Section - Current Version
Details about jvm versions and postgres jdbc drivers helped me figure it out.
I am working on a big project that requires massive financial calculations, I am using
Netbeans IDE 7.3 with a default web application of Java EE 5 (not a maven application)
,My application server is tomcat 7 I am using jsps and servlets my OS is windows 7.
I downloaded and added the jquantlib binary to my application, but when I run it keeps saying that it needs the slf4j-api extension that is not found so i download it also and added its jar to my project but still the error persists.
How can I solve this ? and can anyone give me some guidelines on how to do it ?
The key here is that jquantlib requires slf4j-api version 1.4.0 in the jar manifest:
(from MANIFEST.MF in jquantlib.jar)
Implementation-Vendor-Id: org.jquantlib
Extension-List: slf4j-api
slf4j-api-Extension-Name: slf4j-api
slf4j-api-Implementation-Version: 1.4.0
Tomcat will try to use the version of slf4j-api that you're including in your app, but it's likely that what you've included isn't actually compatible. See http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-catalina/7.0.34/org/apache/catalina/util/Extension.java#Extension.isCompatibleWith%28org.apache.catalina.util.Extension%29 for details.
Bottom line - try to use slf4j-api version 1.4.0 in your application.
Try removing the lines from the MANIFEST.MF file that mention the sfl4j