Affects: 5.1.7.RELEASE
On a Spring Boot 2.1.5.RELEASE application with Spring Cloud Greenwich.SR1 running with OpenJDK 11.0.2, we get the following warning:
WARNING: Illegal reflective access by org.springframework.cglib.core.ReflectUtils (file:/.../org/springframework/spring-core/5.1.7.RELEASE/spring-core-5.1.7.RELEASE.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
at org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:525)
at org.springframework.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:363)
at org.springframework.cglib.proxy.Enhancer.generate(Enhancer.java:582)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:110)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:108)
at org.springframework.cglib.core.internal.LoadingCache$2.call(LoadingCache.java:54)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at org.springframework.cglib.core.internal.LoadingCache.createEntry(LoadingCache.java:61)
at org.springframework.cglib.core.internal.LoadingCache.get(LoadingCache.java:34)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:134)
at org.springframework.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:319)
at org.springframework.cglib.proxy.Enhancer.createHelper(Enhancer.java:569)
at org.springframework.cglib.proxy.Enhancer.createClass(Enhancer.java:416)
at org.springframework.aop.framework.ObjenesisCglibAopProxy.createProxyClassAndInstance(ObjenesisCglibAopProxy.java:57)
at org.springframework.aop.framework.CglibAopProxy.getProxy(CglibAopProxy.java:205)
at org.springframework.aop.framework.ProxyFactoryBean.getProxy(ProxyFactoryBean.java:378)
at org.springframework.aop.framework.ProxyFactoryBean.getSingletonInstance(ProxyFactoryBean.java:330)
at org.springframework.aop.framework.ProxyFactoryBean.getObject(ProxyFactoryBean.java:254)
at org.springframework.cloud.sleuth.instrument.async.ExecutorBeanPostProcessor.getObject(ExecutorBeanPostProcessor.java:199)
at org.springframework.cloud.sleuth.instrument.async.ExecutorBeanPostProcessor.getProxiedObject(ExecutorBeanPostProcessor.java:186)
at org.springframework.cloud.sleuth.instrument.async.ExecutorBeanPostProcessor.createAsyncTaskExecutorProxy(ExecutorBeanPostProcessor.java:169)
at org.springframework.cloud.sleuth.instrument.async.ExecutorBeanPostProcessor.wrapAsyncTaskExecutor(ExecutorBeanPostProcessor.java:147)
at org.springframework.cloud.sleuth.instrument.async.ExecutorBeanPostProcessor.postProcessAfterInitialization(ExecutorBeanPostProcessor.java:92)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsAfterInitialization(AbstractAutowireCapableBeanFactory.java:429)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1782)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:593)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:515)
at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:320)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:318)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:277)
Comment From: jhoeller
This seems to be a side effect of #22416 where we only use the new JDK 9+ defineClass API if the ClassLoader matches... and in this case, the target class seems to come from the system class loader whereas we want to define the proxy in the application's class loader. Let's see whether we can refine our condition to include such cases as well.
Comment From: RobMaskell
Also seeing this, hopefully same issue but posting the log just in case. Spring 5.1.8, openjdk 11
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.springframework.cglib.core.ReflectUtils (file:/home/robm/.gradle/caches/modules-2/files-2.1/org.springframework/spring-core/5.1.8.RELEASE/37fd45c92cfd05b9ad173ee1184ec4221e0f931f/spring-core-5.1.8.RELEASE.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of org.springframework.cglib.core.ReflectUtils
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Comment From: jhoeller
For the time being, these warnings should go away when starting the JVM with --illegal-access=deny since we are going to fall back to the JDK 9+ defineClass API even without a ClassLoader match.
Comment From: xak2000
The same issue (different class loaders) is reproduced when spring-boot-devtools is on classpath.
contextClass.getClassLoader()returnsjdk.internal.loader.ClassLoaders.AppClassLoaderloaderis equal toorg.springframework.boot.devtools.restart.classloader.RestartClassLoader
So, contextClass.getClassLoader() == loader is false.
In my case it was triggered when contextClass was com.zaxxer.hikari.HikariDataSource and com.zaxxer.hikari.HikariConfig. No other classes triggered this path (Classic option: protected ClassLoader.defineClass method).
JDK 11, Spring 5.2.3.RELEASE, Spring Boot 2.2.3.RELEASE
Comment From: oraculo-nl
this might help https://github.com/spring-projects/spring-framework/issues/22814#issuecomment-557456953
Comment From: jhoeller
Aside from several available refinements in recent releases, this is superseded by efforts around #22814 and #26403, to be picked up in corresponding Boot releases.