Maven targets use wrong jars when Flow version has been overridden #19009
Comments
mshabarov
moved this from 🆕 Needs triage
to 🔖 Low Priority (P3)
in Vaadin Flow bugs & maintenance (Vaadin 10+)
mcollovati
added a commit
that referenced
this issue
Oct 25, 2024
Introduces a custom class loader for ClassFinder to ensure resources and classes are loaded first from project dependencies and then from the plugin classloader. Also, augments plugin classloader adding URLs of project artifacts to prevent class cast and class not found exceptions. Fixes #19616 Fixes #19009
9 tasks
mcollovati
added a commit
that referenced
this issue
Nov 12, 2024
Extracts logics from Flow mojos to separated task classes, loaded with a custom class loader composed by project and plugin dependencies, with the firsts having precedence on the others. This make sure classes are always loaded from the same class loader, preventing errors like having a class loaded by plugin class loader, but one of its parent present only in project class loader (see #19616). It also prevents retrieving resources from plugin dependency instead of from same artifact defined in the project (see #19009). This refactoring caches a ClassFinder per execution phase, so that it can be reused by multiple goals configured to run on the same phase. It also removes the need to instantiate a ClassFinder to checking for Hilla classes, limiting the number or scans processed during the build. Fixes #19616 Fixes #19009 Fixes #20385
mcollovati
added a commit
that referenced
this issue
Nov 13, 2024
Run Flow mojos using an isolated class loader that includes both project and plugin dependencies, with project dependencies taking precedence. This ensures that classes are always loaded from the same class loader at runtime, preventing errors where a class might be loaded by the plugin's class loader while one of its parent classes is only available in the project’s class loader (see #19616). Additionally, this approach prevents the retrieval of resources from plugin dependencies when the same artifact is defined within the project (see #19009). This refactoring also introduces caching for ClassFinder instances per execution phase, allowing multiple goals configured for the same phase to reuse the same ClassFinder. It also removes the need to instantiate a ClassFinder solely for Hilla class checks, reducing the number of scans performed during the build. Fixes #19616 Fixes #19009 Fixes #20385
9 tasks
mcollovati
added a commit
that referenced
this issue
Nov 13, 2024
Run Flow mojos using an isolated class loader that includes both project and plugin dependencies, with project dependencies taking precedence. This ensures that classes are always loaded from the same class loader at runtime, preventing errors where a class might be loaded by the plugin's class loader while one of its parent classes is only available in the project’s class loader (see #19616). Additionally, this approach prevents the retrieval of resources from plugin dependencies when the same artifact is defined within the project (see #19009). This refactoring also introduces caching for ClassFinder instances per execution phase, allowing multiple goals configured for the same phase to reuse the same ClassFinder. It also removes the need to instantiate a ClassFinder solely for Hilla class checks, reducing the number of scans performed during the build. Fixes #19616 Fixes #19009 Fixes #20385
github-project-automation
bot
moved this from 🔖 Low Priority (P3)
to ✅ Closed
in Vaadin Flow bugs & maintenance (Vaadin 10+)
mcollovati
added a commit
that referenced
this issue
Nov 20, 2024
Run Flow mojos using an isolated class loader that includes both project and plugin dependencies, with project dependencies taking precedence. This ensures that classes are always loaded from the same class loader at runtime, preventing errors where a class might be loaded by the plugin's class loader while one of its parent classes is only available in the project’s class loader (see #19616). Additionally, this approach prevents the retrieval of resources from plugin dependencies when the same artifact is defined within the project (see #19009). This refactoring also introduces caching for ClassFinder instances per execution phase, allowing multiple goals configured for the same phase to reuse the same ClassFinder. It also removes the need to instantiate a ClassFinder solely for Hilla class checks, reducing the number of scans performed during the build. Fixes #19616 Fixes #19009 Fixes #20385
mcollovati
added a commit
that referenced
this issue
Nov 20, 2024
Run Flow mojos using an isolated class loader that includes both project and plugin dependencies, with project dependencies taking precedence. This ensures that classes are always loaded from the same class loader at runtime, preventing errors where a class might be loaded by the plugin's class loader while one of its parent classes is only available in the project’s class loader (see #19616). Additionally, this approach prevents the retrieval of resources from plugin dependencies when the same artifact is defined within the project (see #19009). This refactoring also introduces caching for ClassFinder instances per execution phase, allowing multiple goals configured for the same phase to reuse the same ClassFinder. It also removes the need to instantiate a ClassFinder solely for Hilla class checks, reducing the number of scans performed during the build. Fixes #19616 Fixes #19009 Fixes #20385
mcollovati
added a commit
that referenced
this issue
Nov 20, 2024
Run Flow mojos using an isolated class loader that includes both project and plugin dependencies, with project dependencies taking precedence. This ensures that classes are always loaded from the same class loader at runtime, preventing errors where a class might be loaded by the plugin's class loader while one of its parent classes is only available in the project’s class loader (see #19616). Additionally, this approach prevents the retrieval of resources from plugin dependencies when the same artifact is defined within the project (see #19009). This refactoring also introduces caching for ClassFinder instances per execution phase, allowing multiple goals configured for the same phase to reuse the same ClassFinder. It also removes the need to instantiate a ClassFinder solely for Hilla class checks, reducing the number of scans performed during the build. Fixes #19616 Fixes #19009 Fixes #20385
mcollovati
added a commit
that referenced
this issue
Nov 20, 2024
Run Flow mojos using an isolated class loader that includes both project and plugin dependencies, with project dependencies taking precedence. This ensures that classes are always loaded from the same class loader at runtime, preventing errors where a class might be loaded by the plugin's class loader while one of its parent classes is only available in the project’s class loader (see #19616). Additionally, this approach prevents the retrieval of resources from plugin dependencies when the same artifact is defined within the project (see #19009). This refactoring also introduces caching for ClassFinder instances per execution phase, allowing multiple goals configured for the same phase to reuse the same ClassFinder. It also removes the need to instantiate a ClassFinder solely for Hilla class checks, reducing the number of scans performed during the build. Fixes #19616 Fixes #19009 Fixes #20385
|
This ticket/PR has been released with Vaadin 24.4.18. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the bug
If you create an application using Vaadin 24 alpha 15 and override the Flow version from alpha22 to alpha23, then
mvn vaadin:build-frontendwill generate package.json using Flow alpha22 and not alpha23 (e.g.@babel/preset-reactwill be^7and not7.23.3).This apparently happens because that the class loader created using the URLs from the project compile path (these URLs are correct and include Flow alpha 23) is set to use the context class loader as the parent class loader here:
flow/flow-plugins/flow-plugin-base/src/main/java/com/vaadin/flow/server/scanner/ReflectionsClassFinder.java
Lines 59 to 60 in ba28266
Now the context class loader apparently contains the plugin dependencies and as the plugin was built using Flow alpha22, it contains a reference to that. Class loader specs also say that any class loader should first try the parent class loader, so when trying to find e.g.
com/vaadin/flow/server/frontend/dependencies/vite/package.jsonthen the created class loader will first consult the parent, which finds flow-server alpha22 and returns the URL to the resource.Expected behavior
The project classpath would be used, not the classpath used to create the plugin
Minimal reproducible example
New project + Flow override, as described
Versions
The text was updated successfully, but these errors were encountered: