-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Propagate Bean ClassLoader
to MongoTypeMapper
#3905
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
Comments
This issue is indeed related to the class loader that is being used. Running the packaged jar uses Spring Boot code to create a class loader for the packaged jar files. Running the project from the IDE comes with the JDK's app-classloader that has already all jars on the class path. Specifically, obtaining the default classloader from the When you look into Likely the difference is motivated by the assumption of a single You can supply a custom Alternatively, annotate your concrete classes with a type alias annotation Paging @wilkinsona for awareness. |
Thanks, @mp911de. This is due to a somewhat unfortunate change in Java 9 that we've seen a few times before. See spring-projects/spring-boot#19427, for example. |
Thanks. Too bad this inconsistency is there. It's a bit of a booby trap. I had not picked up on the ability to work around this issue with the I also observe that it requires some extra work in the build to set ForkJoinPool.commonPool()'s threadFactory, e.g.,
does not work unless the custom factory class is at the root of the jar. But it looks like the |
I wonder whether we could default to the Spring ClassLoader in |
Thanks! 👍 |
ClassLoader
to DefaultTypeInformationMapper
Reopening the ticket as we can use the container's |
ClassLoader
to DefaultTypeInformationMapper
ClassLoader
to MongoTypeMapper
We now set the ClassLoader from the ApplicationContext to the type mapper to ensure the type mapper has access to entities. Previously, `SimpleTypeInformationMapper` used the contextual class loader and that failed in Fork/Join-Pool threads such as parallel streams as ForkJoinPool uses the system classloader. Running e.g. a packaged Boot application sets up an application ClassLoader that has access to packaged code while the system ClassLoader does not. Also, consistently access the MongoTypeMapper through its getter. Closes #3905
Description
When I read a document using a repository, if the document has an abstract field with a concrete implementation and the first read of the document happens in a ForkJoinPool thread, the read fails with the following stacktrace:
Steps to Reproduce
I have created a project on github that illustrates the issue.
Environment I'm Using
OSX 11.6
mongodb 4.2.10
Spring Boot 2.5.7
java:
Observations
I believe the issue is due to the classloader available when using ForkJoinPool. I do not consistently see the problem when running in my IDE (IntelliJ 2021.2.2), but I do consistently see it when running the built app. I can work around the issue using a custom ForkJoinWorkerThreadFactory, e.g.
The text was updated successfully, but these errors were encountered: