java.lang.VerifyError: $$EnhancerBySpringCGLIB$$744256ce, method: <init> signature: ()V) Illegal type in constant pool [SPR-13098]

[spring-projects-issues]

Narasimha opened SPR-13098 and commented

Hi,

Recently we migrated our project from Spring 3.X to Spring 4.0.9. We did this upgradation for Java8 support and Tomcat 7.0.59 support. And currently migrating the project to full Spring MVC.

We have a requirement like some of our controllers might night be instantiated out of Spring. For that we have used @Configurable annotation. Everything is working fine so far.

Now the requirement came like we need to introduce an aspect to do some operation dynamically. For example we need to execute a method on the target object when a particular annotation is available on the method.

We are using LoadTimeWeaving , I did all configuration as per spring documents. But whenever I am starting the server I am getting the following error.

java.lang.VerifyError: (class: XXXServiceSpringMvc$$EnhancerBySpringCGLIB$$744256ce, method: <init> signature: ()V) Illegal type in constant pool
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:386)
at org.springframework.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:219)
at org.springframework.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
at org.springframework.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
at org.springframework.aop.framework.ObjenesisCglibAopProxy.createProxyClassAndInstance(ObjenesisCglibAopProxy.java:57)
at org.springframework.aop.framework.CglibAopProxy.getProxy(CglibAopProxy.java:202)
at org.springframework.aop.framework.ProxyFactory.getProxy(ProxyFactory.java:109)
at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.createProxy(AbstractAutoProxyCreator.java:496)
at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.wrapIfNecessary(AbstractAutoProxyCreator.java:381)
at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessAfterInitialization(AbstractAutoProxyCreator.java:341)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsAfterInitialization(AbstractAutowireCapableBeanFactory.java:421)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1559)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:539)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:475)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:302)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:229)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:298)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:706)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:762)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)
at org.springframework.web.servlet.FrameworkServlet.configureAndRefreshWebApplicationContext(FrameworkServlet.java:658)
at org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:624)
at org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:672)
at org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:543)
at org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:484)
at org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:136)
at javax.servlet.GenericServlet.init(GenericServlet.java:158)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5262)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5550)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

---

Affects: 4.0.9

Issue Links:

• ObjenesisCglibAopProxy's fallback mode triggers duplicate class definition error [SPR-13131] #17722 ObjenesisCglibAopProxy's fallback mode triggers duplicate class definition error

[spring-projects-issues]

Juergen Hoeller commented

This seems to be a rather weird class format incompatibility at the point of CGLIB proxy creation... We haven't really changed anything in that space except for a CGLIB version upgrade, so this is rather puzzling.

Have you tried upgrading to Spring Framework 3.2.13? It would be interesting to know whether you're seeing the same failure there. And since the late 3.2.x line has Java 8 runtime support now (just no support for specific Java 8 API features), you could even upgrade to 3.2.x to begin with - at least until we've figured out that CGLIB failure.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Oh, and please note that Spring Framework 4.0.9 is a dead end in the meantime. We're just actively maintaining 4.2 and 4.1.x at this point, next to basic maintenance for 3.2.x. From that perspective, for further attempts against Spring Framework 4.x, please use 4.1.6 or the upcoming 4.1.7 instead.

[spring-projects-issues]

Narasimha commented

HI,

Thanks a lot for your quick response.

As suggested by you , I have upgraded spring version to 4.1.6.RELEASE.

But still I am getting the same error, after debugging the code I came to know that Spring-core has one class "org.springframework.objenesis.ObjenesisStd" and this was compiled with java 1.5 and not supporting my Java 8 run time.

I saw the below error when i try to acces the file from my STS(Spring tool suite).
// Compiled from ObjenesisStd.java (version 1.5 : 49.0, super bit)

Actually the class ObjenesisCglibAopProxy.java executes the following code.

@Override
@SuppressWarnings("unchecked")
protected Object createProxyClassAndInstance(Enhancer enhancer, Callback[] callbacks) {
try {
Factory factory = (Factory) this.objenesis.newInstance(enhancer.createClass());
factory.setCallbacks(callbacks);
return factory;
}
catch (ObjenesisException ex) {
// Fallback to regular proxy construction on unsupported JVMs
if (logger.isDebugEnabled()) {
logger.debug("Unable to instantiate proxy using Objenesis, falling back to regular proxy construction", ex);
}
return super.createProxyClassAndInstance(enhancer, callbacks);
}
}

Here it will try to invoke org.springframework.objenesis.ObjenesisStd and there java compatability issue is araising.

Could you please suggest me what I can do now?

Thanks

[spring-projects-issues]

Juergen Hoeller commented

It shouldn't matter that Objenesis is compiled for JDK 5 as a target, if that's what you're suspecting... Many libraries are compiled like that and work just fine on JVM 8; it's one of the great benefits of JVM backwards compatibility.

That said, Objenesis may cause other effects here. It is effectively trying to create an instance without invoking a constructor, and this only works through internal JVM APIs which may potentially cause hassle. However, the odd part in your stacktrace is that the class definition failure occurs within CGLIB, a step before Objenesis actually gets involved...

Juergen

[spring-projects-issues]

Narasimha commented

Hi,
first of all thanks a lot for your quick response and support.

I also agree with you.I am vexed with this one.
nothing is in my head now. Could you please let me know how can I fix this.

[spring-projects-issues]

Narasimha commented

HI,

Could you please let me know if there is any further update on this issue?

Thanks

[spring-projects-issues]

Juergen Hoeller commented

Unfortunately I have no insight into the root cause yet. It might have something to do with a specific class arrangement of yours that the combination of load-time weaving, CGLIB and Objenesis isn't able to process correctly. A minimal reproduction project would be great...

For the time being, the best that I can recommend is to upgrade to Spring Framework 3.2.13 instead. At least you'll get full Java 8 and Tomcat 7 runtime compatibility there as well.

Juergen

[spring-projects-issues]

Narasimha commented

Hi Juergen,

Finally I fixed this issue. It's not problem with Java (initially I misleaded by the error as we have upgraded to Java8).

The actual cause is that I have multiple context files.

1. applicationContext.xml
2. servlet-mvc-context.xml

when I enable load time weaving in applicationContext and placed @Configurable on top of @Controller. I am getting this error.
For eample:
@Configurable
@Controller
public class HelloController {

To fix this I have moved load time weaving configuration to servlet-mvc-context.xml as below.
<context:load-time-weaver aspectj-weaving="on"/>

This issue got fixed.

What I didn't understand is , if I enable Load time waving in applicationContext.xml file by removing @Configurable annotation , it's working as expected without any issues. But I am getting this error only when I keep @Configurable on top of @Controller and enable load time weaving in applicationContext.xml rather than spring-mvc.xml.

If possible could you please help me in understanding the concept behind this.

Thanks
Narasimha