New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Class loading is broken with Spring Boot's DevTools again. #396
Comments
Hi Michael, #331 is about shutdown hooks, and ClassGraph doesn't use those anymore. It's that the issue you meant to link? I don't use or really know anything about Spring, and I'm currently traveling internationally. Do you know how to solve the issue, or would you be able to dig into it please? |
Yes, this is the correct issue. Things break between 4.8.17 and 4.8.19 (4.8.18 seems not to be available in Maven central). You even address the original issue here #331 (comment) That's not that much about Spring to know, the order of class loaders is wrong again after some commit between 4.8.17 and 4.8.19. I cannot fix this myself, but we can only work around in OGM by not using the class loading mechanism of ClassGraph, which is kinda sad. |
It doesn't look like just a delegation issue, since RestartClassLoader is not even present in the second case. What do the ClassGraph verbose logs say is happening with RestartClassLoader? |
The restart class loader is used by the application. We have been there before. The Here are some excerpt from the verbose output I think are relevant:
|
I tried your example project. Your
Any ideas as to why it works for me but not for you? |
@michael-simons I took a stab in the dark and guessed that maybe in your case, one of the context classloaders is the same as the restart classloader's parent. Please test the above change -- fingers crossed it will fix the issue. |
See the pom, I attached a version that worked. You have to change it to something >= 4.8.19 Than run with |
Still fails with your patch.
Executed with |
I changed the version in the pom to 4.8.19. It succeeds using both |
OK, I figured out how to reproduce it. It can only be reproduced on JDK 7/8. |
Strangely though in JDK 8, if I run Gh729Application in the Eclipse debugger, it never runs the Reproducer component. (It does if I run it in JDK 12.) So I don't know how to debug this. I have tried several things, but can't figure out how to get the Reproducer to run anywhere but the commandline... |
I figured it out. I erroneously assumed that the Restart classloader didn't actually do any classloading itself, but only delegated to the context classloader first, and then the parent classloader last. Turns out there are cases where there is no context classloader other than the Restart classloader, and in that case, it does its own classloading. Fixed and released in 4.8.60. Sorry for the trouble! |
Actually now that I understand the Restart classloader better, I made some further cleanups to simplify the |
Great work, Luke! I can confirm both 4.8.60 and 4.8.61-SNAPSHOT works. |
Great! Thanks for the bug report, test case, and testing! |
Title: Issue with ClassGraph Version 4.8.29 on Specific Server Machines I encountered an issue with ClassGraph when using version 4.8.29 on my server cluster. Some of the machines in the cluster fail to use ClassGraph classes correctly, while others operate without any problems. It seems that this issue is related to the specific models of the machines. The machines that fail produce the following error: "a fault occurred in a recent unsafe memory access operation in compiled Java code."LogicalZipFile.readCentralDirectory(LogiclaZipFile.java439) Interestingly, when I upgrade the ClassGraph jar to version 4.8.60, this problem no longer occurs. It seems that something in the update from 4.8.29 to 4.8.60 has resolved the issue. I am curious to know what changes were made in version 4.8.60 that might have addressed this problem. Any insights or information would be greatly appreciated. Thank you. |
@lbjzz-hash Version 4.8.60 is 105 minor releases behind the latest version. I would only look this far back in the release history if I needed to do a |
Hello Luke,
Sadly #331 introduced a regression of #267.
That became apparent in a change of Neo4j-OGM where we now rely on ClassGraph being able to find scanned classes.
Find attached a reproducer:
This works in 4.8.17 and starts to fail in 4.8.19 again (as before my contribution).
This is the expected order of class loaders with
org.springframework.boot.devtools.restart.classloader.RestartClassLoader
presentThis is now what I get in 4.8.19+
Both screenshots from debugging into
io.github.classgraph.ClassGraphClassLoader
and displaying the order of class loaders used.Find the reproducer attached. Open in your IDE and run
Gh729Application
.gh729.zip
Related OGM ticket is neo4j/neo4j-ogm#729
The text was updated successfully, but these errors were encountered: