I want to use Java 9 with Spring. But I get exception:
Caused by: org.springframework.aop.framework.AopConfigException: Unable to instantiate proxy using Objenesis, and regular proxy instantiation via default constructor fails as well; nested exception is java.lang.NoSuchMethodException: org.springframework.boot.autoconfigure.http.HttpMessageConverters$$EnhancerBySpringCGLIB$$1d90bff9.<init>()
at deployment.datalis_gateway.war//org.springframework.aop.framework.ObjenesisCglibAopProxy.createProxyClassAndInstance(ObjenesisCglibAopProxy.java:82)
at deployment.datalis_gateway.war//org.springframework.aop.framework.CglibAopProxy.getProxy(CglibAopProxy.java:205)
... 62 more
Caused by: java.lang.NoSuchMethodException: org.springframework.boot.autoconfigure.http.HttpMessageConverters$$EnhancerBySpringCGLIB$$1d90bff9.<init>()
at java.base/java.lang.Class.getConstructor0(Class.java:3302)
at java.base/java.lang.Class.getDeclaredConstructor(Class.java:2512)
at deployment.datalis_gateway.war//org.springframework.aop.framework.ObjenesisCglibAopProxy.createProxyClassAndInstance(ObjenesisCglibAopProxy.java:76)
... 63 more
Do you know how I can configure Java 9 to find this restricted Java package?
I came across the same error when trying to deploy a Spring Boot 2 application to Wildfly 13. This is the only Stack Overflow question that came up when I was searching for answers, so I thought I'd leave my findings here in case anyone else has the same issue, because my solution was very different from the only other answer here right now.
My application would run just fine using the embedded Tomcat server, but deploying to Wildfly would fail with the same AopConfigException asked about in this question. I also noticed in the root cause of the exception that Spring was looking for a no-arg constructor, and when I added no-arg constructors in all my autowired Spring components, the service actually deployed to Wildfly and ran with no problems. But this seemed like a hacky workaround that felt wrong, so I looked for a better solution.
I learned from this github issue that this exception happens in Wildfly because Jboss Modules are not exposing some dependencies needed by Objenesis to do constructor injection. The suggested solution they give is to add the dependencies by simply updating the project build as follows:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<archive>
<manifestEntries>
<Dependencies>jdk.unsupported</Dependencies>
</manifestEntries>
</archive>
</configuration>
</plugin>
If this works for you, congratulations. I pieced together from this JBoss issue that the above solution is simply a way of adding "jdk.unsupported" as a "Dependency" in the MANIFEST.MF file. Unfortunately for me, this is part of a Maven pom, and my team uses Gradle for build management, so I had to find another solution.
Solution that works in Gradle OR Maven
Although there is probably a Gradle specific way to accomplish the above, I found from this JBoss development guide that you can add a dependency into the MANIFEST.MF using the jboss-deployment-structure.xml with the following contents:
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="jdk.unsupported"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
This seems like the preferred solution even if you do use Maven because it will work the same if you switch to Gradle down the road. Of course, this solution only works if the issue is isolated to JBoss/Wildfly.
*Note (in case the link to the JBoss guide goes down): jboss-deployment-structure.xml file goes in the WEB-INF or META-INF directory for a war/jar application respectively.
Also worth noting, I am seeing this issue on Java 11 and Wildfly 13, but I very strongly suspect that the same issue exists on Java 9 and 10 and on other versions of JBoss/Wildfly as well.
In my case VM argument --add-modules=jdk.unsupported helped. In this case ObjenesisCglibAopProxy creates a proxy using sun.reflect.ReflectionFactory and doesn't look for the absent constructor.
if you add jdk.unsupported as global module, you need not change the applications:
<global-modules>
<module name="jdk.unsupported"/>
You need to use a couple of --add-opens to your runtime JVM arguments and be prepared to add opens ... just about everywhere in your application that exposes something to the Spring context that isn’t exported yet.
More information
The issue seem to be with the java compiler version. I got this error when the compiled code was java version 11 and if I change the compiler to 8 I didn't see th
Related
I've found a similar question here , but it points to a plugin that I'm not using (maven-failsafe-plugin), and the configuration that solution is referring to is not applicable for me.
The problem is that since I've updated my jetty plugin from
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.3.9.v20160517</version>
to <version>9.4.11.v20180605</version> , it started to spam hundreds of warnings like
[WARNING] org.apache.axis2.description.java2wsdl.bytecode.ClassReader scanned from multiple locations: jar:file:///C:/Users/a0763323/.m2/repository/org/apache/axis2/axis2-kernel/1.4.1/axis2-kernel-1.4.1.jar!/org/apache/axis2/description/java2wsdl/bytecode/ClassReader.class, jar:file:///C:/Users/a0763323/.m2/repository/it/aon/WSInfocar/1.2/WSInfocar-1.2.jar!/org/apache/axis2/description/java2wsdl/bytecode/ClassReader.class
[WARNING] org.apache.axis2.description.java2wsdl.bytecode.MethodTable scanned from multiple locations: jar:file:///C:/Users/a0763323/.m2/repository/org/apache/axis2/axis2-kernel/1.4.1/axis2-kernel-1.4.1.jar!/org/apache/axis2/description/java2wsdl/bytecode/MethodTable.class, jar:file:///C:/Users/a0763323/.m2/repository/it/aon/WSInfocar/1.2/WSInfocar-1.2.jar!/org/apache/axis2/description/java2wsdl/bytecode/MethodTable.class
[WARNING] org.apache.axis2.description.java2wsdl.bytecode.ParamNameExtractor scanned from multiple locations: jar:file:///C:/Users/a0763323/.m2/repository/org/apache/axis2/axis2-kernel/1.4.1/axis2-kernel-1.4.1
I've searched everywhere but I can't understand neither what that means or how to resolve this.
I'm using IntelliJ and maven compiler plugin
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
Thanks
Lets break it down ...
[WARNING] org.apache.axis2.description.java2wsdl.bytecode.ClassReader scanned from multiple locations:
jar:file:///C:/Users/a0763323/.m2/repository/org/apache/axis2/axis2-kernel/1.4.1/axis2-kernel-1.4.1.jar!/org/apache/axis2/description/java2wsdl/bytecode/ClassReader.class,
jar:file:///C:/Users/a0763323/.m2/repository/it/aon/WSInfocar/1.2/WSInfocar-1.2.jar!/org/apache/axis2/description/java2wsdl/bytecode/ClassReader.class
You have the class org.apache.axis2.description.java2wsdl.bytecode.ClassReader coming from 2 different JARs (and seemingly on two different versions!)
Judging from your filesystem paths you likely have the following maven dependencies ...
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-kernel</artifactId>
<version>1.4.1</version>
</dependency>
<dependency>
<groupId>it.aon.WSInfocar</groupId>
<artifactId>WSInfocar</artifactId>
<version>1.2</version>
</dependency>
It's unwise in the extreme to have two different versions of the same class on your classpath / classloader (it's very easy to have 1 version be used and then passed to a different class on the other version that will not understand it or be able to use it)
You'll need to resolve, manually, which one you should be using.
You might want to ask the developers of the WSInfocar why they are bundling axis in their own artifact as well.
I found this question and reply most helpful. I had a conflict with the JDT Core and the Java Eclipse compiler. I went to Properties and clicked on Java Compiler changing one thing at a time and testing. Changing from using JRE 1.8 to JRE 11 run time resolved it for me somewhere in all the things I tested.
I have checked:
Enable Project Specific Setting
Use Default Compliance Settings (1.8)
This puts up a notice:
When selecting 1.8 compliance be sure to have a compatible JRE installed and activated (currently 11). Configure the installed JRE or execution environment or change the build path.
Again, change one thing at a time then test. I specifically went with a 1.8 JRE because I read Java 11 does not ship a JRE. I am still not clear on that subject.
I find this problem solution all day, and if you want ignore the WARN log in jetty, you can try this:
--exec
-Dorg.eclipse.jetty.annotations.AnnotationParser.LEVEL=OFF
append these code in start.ini jetty file, and restart jetty.
2022 Update: the Pengwei method currently (Jetty 9) works by using this property:
java -Dorg.slf4j.simpleLogger.log.org.eclipse.jetty.annotations.AnnotationParser=ERROR ...
This can usually be injected into JVM via:
export JAVA_TOOL_OPTIONS="-Dorg.slf4j.simpleLogger.log.org.eclipse.jetty.annotations.AnnotationParser=ERROR"
run-java.sh # eg, catalina.sh
And also in Maven command line:
mvn -Dorg.slf4j...=ERROR
It is also possible to tweak Maven logging properties for all of your projects. However, that's not recommended, since, as already mentioned, these warnings might be relevant and a source of problems. In fact, as you see, I'm proposing to set at least the ERROR level, not to disable the scanner logger completely.
First off, I'm a long time user (and beneficiary) of StackOverflow, but this is my first question. I've done plenty of searching on this topic, but most of the articles I've turned up talk about generating JAR files, not working with 3rd party JARs from the Maven Central repo which I don't really have the power to fix. The few solutions I've seen floating around aren't really acceptable.
The problem is that most of the jaxb JARs found in the Maven Central repository contain classpath entries (in the MANIFEST.MF file) that point to dependencies, and those dependencies are specified with relative paths -- typically assuming that dependency bar.jar exists in the same directory as foo.jar.
This is fine if you have all your JAR dependencies in a single lib directory, for example. But:
Maven wants to maintain its own local repository, so every single packaged JAR lives in its own directory (with each version in a separate subdirectory).
Maven JARs are typically named with the version info embedded in the filename, whereas the classpath entry in MANIFEST.MF specifies the dependency with just the base filename (no version).
The net result is an error message like this:
[ERROR] bad path element
"C:\Users\rpoole\.m2\repository\com\sun\xml\bind\jaxb-impl\2.2.11\jaxb-core.jar":
no such file or directory
One solution is to write a script or small app to go through all the JARs and strip out the classpath info from the embedded MANIFEST.MF file. But that is not very clean, and requires an extra step before doing the actual build.
Another potential solution is that some newer published versions of the JARs in question have supposedly fixed this classpath problem, so therefore use the latest and greatest. Unfortunately, this app I'm working on is legacy, and is being developed for a 3rd party, so I can't update the dependencies beyond a certain version. So far, all the jaxb JARs that I have poked into seem to have issues.
Is there a way to tell Maven to ignore the embedded classpath in the JAR and only rely on Maven's own dependency resolution? I've tried things like reordering dependencies, but that doesn't work (or moves the build problem from one subproject to another).
One additional annoyance: There is a "blessed" Maven repo we have that seems to let the build complete with no problem, but so far I've been unable to figure out why this particular set of JARs builds OK. I suspect someone may have gone in and tweaked some JARs or POMs manually, but there's scant information, and diff tools aren't really helping much.
Regardless, the project should build from scratch.
What would be nice is if I could specify something like an exclusion block in the pom.xml for the subproject that's breaking, but for dealing with a JAR's embedded classpath instead of Maven's own transitive dependencies (specified by groupId/artifactId).
Edit: Apparently, some people believe that this is impossible, and that Maven ignores the Class-Path entry in Manifest.MF. However, this is a known issue, as discussed in this StackOverflow article. There's also another good article which explains some of the history of this a bit better.
The problem is that I can't go through the JARs and edit the MANIFEST.MF files on each as part of the build process. That's just not a practical approach, even if automated by script. I need a solution that actually will work for code that is already in production. These issues were supposedly fixed in later versions of the JARs in question, but I may not be able to use newer versions of those.
Additionally, one of the proposed fixes is to add -Xlint:-path to the compiler args, which suppresses the error message. However, the build simply fails at another point for me, so at first blush this does not appear to be a good solution either. I'll be trying this again because according to this, the syntax for compiler arguments inside POM files is a bit wonky.
I hate answering my own question, but I finally did manage to get past this problem. For those who keep insisting that Maven builds can't possibly be affected by the Class-Path entry in a jar's MANIFEST.MF, please read this article by Michael Bayne. It summarizes the problem and the solution rather nicely. Hint: javac certainly does care about the embedded classpath in jars.
The trick is to add -Xlint:-path to the compiler arguments, although I was dubious of this solution initially. Doing this will suppress the bad path element warnings/errors, and therefore Maven won't prematurely halt the build. The problem I had was figuring out the correct syntax for embedding these arguments in the pom.xml. That's where this article comes in handy. Therefore, the compiler plugin's configuration has to look like this to be understood properly:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>${java-version}</source>
<target>${java-version}</target>
<compilerArguments>
<Xlint/>
<Xlint:-path/>
</compilerArguments>
<showWarnings>true</showWarnings>
<showDeprecation>true</showDeprecation>
</configuration>
</plugin>
</plugins>
Note that this syntax is not very good XML (as Bayne points out), and most IDEs will flag the second Xlint line as an error, but it will work with Maven. Using the syntax given in some Maven tutorials may result in the arguments not being passed to the compiler at all, or only the last argument being passed.
Once this problem is taken care of, you may discover other build problems (I certainly did), but at least those problems won't be hidden from you any longer.
The problem is that you are referencing a post which is seven years old..and don't use more recent versions of the maven-compiler-plugin:
The arguments to the javac compiler can better done like this:
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.6.1</version>
<configuration>
<compilerArgs>
<arg>-Xlint</arg>
<arg>-Xlint:-path</arg>
</compilerArgs>
</configuration>
</plugin>
</plugins>
[...]
</build>
[...]
</project>
I'm developing a java web application using java. To develop this application I'm using jetty as application server. Up to now the following version:
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>7.4.2.v20110526</version>
</plugin>
After some changes in the application, I decide to change my jetty version with the following:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.2.13.v20150730</version>
</plugin>
But i noticed a performance lack during the execution of jetty:run.
I noticed that it loses almost a minute on
2015-10-07 12:59:11.863:INFO:oejs.Server:main: jetty-9.2.13.v20150730
How can I understand why?
Update 1
I think that my problem could be similar at the following:
Jetty startup delay due to scanning
then I thought to solve my problem using quick-start module, is this possible using jetty-embedded?
Your problem is indeed most probably caused by scanning. The link you've found has helpful info on it.
I have also just updated the documentation for the jetty-maven-plugin to make it clear that you can also set the patterns for container and webapp jar scanning with the plugin. The page is here: https://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html#configuring-your-webapp but it will take the CI system a little while to push out the update (look for items on setting the containerIncludeJarPattern and the webInfIncludeJarPattern).
As the document already mentions under the goal "effectiveWebXml", using quickstart explicitly with the maven plugins is not really appropriate.
Jan
Recently I configured my application to use "skinny wars" that was described on codehaus (title: Solving the skinny war problem). Basically I exclude all jars from the war and add it as a war and pom dependency to the ear. Now I ran into a problem with two jars. So to me the logical thing to do was include them in the war file using packagingInclude.
<plugin>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>
<packagingIncludes>WEB-INF/lib/A.jar, WEB-INF/lib/B.jar</packagingIncludes>
</configuration>
</plugin>
Using a regex as showed in de plugin documentation and this answer but it didn't seem to do anything. It just excludes everyting.
In the source code of the plugin I found that it uses the DocumentScanner of org.codehaus.plexus » plexus-utils. I didn't quite understand how it works.
I thought this was a no brainer. But what am I doing wrong? Could it be that the inclusion doesn't work when A is also a transitive dependency of C?
Edit: Does plugin version play any role? Now I am using 2.6 but previously version 2.1-alpha-2 was used.
Found this answer as well. The following line (and only this line) works:
<packagingExcludes>%regex[WEB-INF/lib/(?!common-A|common-B).*.jar]</packagingExcludes>
Only common-A-x.x.jar and common-B-x.x.jar are in the WEB-INF/libfolder of the war file. It should be possible to extract the common part in the regex but what I tried didn't work.
try to use the includes only without the wildcard excludes definition. Since you exclude all jars this eats up your includes. As far as I understand the doc (and from my memories), the default is to include everything but as soon as you specify an include the plugin will only include your list of jars.
I have a Maven project (ejb container) where I need to use the jcifs library.
I made the entries in pom.xml like:
<dependency>
<groupId>jcifs</groupId>
<artifactId>jcifs</artifactId>
<version>1.3.17</version>
<type>jar</type>
</dependency>
Everything is okay, I see the jar file inside the ear package, I see it also in the dependencies of the project, I can use the classes but at runtime I get:
javax.ejb.EJBException: java.lang.RuntimeException: java.lang.NoClassDefFoundError: jcifs/smb/SmbFile
at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:63)
What am I doing wrong?
Right-click the webproject and go to properties -> Java EE Module Dependencies. Check the Maven dependencies is checked.If not check and redeploy .
I would like to help the people who are as stupid as I am. This is not really the about the same scenario as asked for in this question, but this question helped me to figure out my problem.
I wrote a little code in a scratch file, in my case in Intellij. Before that I added the jcifs dependency to my maven project, assuming that the scratch file would find it there, which in hindsight is a bit stupid, because how would the scratch space know.
So my hint is to have a look where the dependency will actually have an effect, i.e. is available - compile time, runtime, scratch space?
Also I wanted to mention that I used this library, which works very fine for me https://github.com/hierynomus/smbj.
So in my case I edited the run configuration so that it would take the maven modules configuration into the classpath.
So my guess is that #SANN3 's answer is correct for the actual question.