Peter Penzov
Peter Penzov

Reputation: 1716

NoSuchMethodException: springframework.boot.autoconfigure.http.HttpMessageConverters

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?

Upvotes: 8

Views: 10483

Answers (5)

srinivas muthyam
srinivas muthyam

Reputation: 1

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

Upvotes: 0

weberjn
weberjn

Reputation: 1985

if you add jdk.unsupported as global module, you need not change the applications:

<global-modules>
      <module name="jdk.unsupported"/>

Upvotes: 1

Hazeh
Hazeh

Reputation: 51

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.

Upvotes: 5

Jarrett Munton
Jarrett Munton

Reputation: 301

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.

Upvotes: 30

Maxim Kasyanov
Maxim Kasyanov

Reputation: 1058

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

Upvotes: 0

Related Questions