Production build fails if Spring Boot Application implements AppShellConfigurator and is annotated with a Spring Data JPA Repository #19616
Assignees
Labels
BFP
Bugfix priority, also known as Warranty
bug
Impact: High
Released with Vaadin 24.4.18
Severity: Major
workaround
Comments
|
My guess is that this happens because, even though the dependencies' scanner is using the project classpath, the maven plugin goal is executed within the plugin classpath. |
|
Related draft PR #19010 |
|
Workaround should be moving the |
mcollovati
moved this to 🔖 Normal Priority (P2)
in Vaadin Flow bugs & maintenance (Vaadin 10+)
|
Another workaround would be to implement a separate class for AppShellConfigurator |
|
I had the exact same problem in December 2021 with vaadin-maven-plugin:9.0.0 . |
|
After update to last vaadin version got same problem, and I can't find fix for now (suggestion not works as expected) |
|
And yes, its repositoryFactoryBean. Moving
|
|
Did you try my workaround, too? |
|
What I tested, and that not works:
Now impossible build project, and I reverted upgrade. Also checked - due analyzer run on every annotated class, he will anyway throw exception on other class (all views, etc). Because JDK code from Class |
|
@VISTALL a couple of questions:
|
|
@mcollovati Yes - And yes. |
|
I can reproduce if I put a Can you share the code of the Application class? Annotations and definitions should be enough, no need for the whole class. |
|
It's company code - not possible. But as you said. App implement AppShellConfigurator and @EnableJpaRepositories exists. If I move implementation of AppShellConfigurator to another class (just for it) - problem persist.
|
|
Moving all Vaadin annotations to another class seems to work. Give the above snippet it would be like @SpringBootApplication(scanBasePackages = ?")
@EnableCaching
@EnableScheduling
@EntityScan(basePackages = "?")
@EnableJpaRepositories(basePackages = "?")
@ComponentScan(excludeFilters = @ComponentScan.Filter(type = FilterType.REGEX, pattern = "?"))
public class Application {and @Push(value = PushMode.MANUAL, transport = Transport.WEBSOCKET)
@Theme("?")
@NpmPackage(value = "@fortawesome/fontawesome-free", version = "6.4.0")
@Uses(RadioButtonGroup.class)
@Uses(TextArea.class)
@Uses(ApexCharts.class)
@Uses(Accordion.class)
@Uses(DateTimePicker.class)
@Uses(ComboBox.class)
@Uses(NumberField.class)
@Uses(Checkbox.class)
@Uses(ProgressBar.class)
@Uses(Button.class)
@Uses(IntegerField.class)
@Uses(ColorPicker.class)
@Uses(AceEditor.class)
@Uses(ToggleButton.class)
@Uses(VirtualList.class)
@Uses(Upload.class)
@Uses(TinyMce.class)
@JsModule("./clipboard/clipboard.js")
@NpmPackage(value = "@esotericsoftware/spine-player", version = "4.1.51")
@StyleSheet("@esotericsoftware/spine-player/dist/spine-player.min.css")
public class AppShell implements AppShellConfigurator { |
|
And. Looks like it helps. Thanks. Ambiguous problem, code was legal before update (and there no info about limitation) |
|
It looks like that in 24.3 the class scan is not performed during |
|
Will be nice to see fix in near future :) |
mcollovati
added a commit
that referenced
this issue
Jul 25, 2024
Wraps the annotation finder function to log potential errors during class scanning and the class that originates the failure. References #19616
mcollovati
added a commit
that referenced
this issue
Jul 25, 2024
Wraps the annotation finder function to log potential errors during class scanning and the class that originates the failure. References #19616
mcollovati
added a commit
that referenced
this issue
Jul 26, 2024
Wraps the annotation finder function to log potential errors during class scanning and the class that originates the failure. References #19616
vaadin-bot
pushed a commit
that referenced
this issue
Jul 26, 2024
Wraps the annotation finder function to log potential errors during class scanning and the class that originates the failure. References #19616
vaadin-bot
pushed a commit
that referenced
this issue
Jul 26, 2024
Wraps the annotation finder function to log potential errors during class scanning and the class that originates the failure. References #19616
vaadin-bot
added a commit
that referenced
this issue
Jul 26, 2024
|
I fixed this issue with two main steps. First, I created an AppShell class, extending AppShellConfigurator. I put all the Vaadin related annotations from the app class into it. Next, I went into /.m2/repository and deleted everything. After doing that, I ran mvn clean install, which succeeded and then I ran the app with mvn spring-boot:run and it started up as expected. |
|
Moving @EnableJpaRepositories to another class with @configuration worked for me as a workaround using 24.4.10 - but would be nice for there to be a proper fix for this given the impact. |
mshabarov
moved this from 🔖 Normal Priority (P2)
to 🔖 High Priority (P1)
in Vaadin Flow bugs & maintenance (Vaadin 10+)
|
Let us prioritise this for next dev iteration (next two weeks). Stay tuned. |
|
The issue was triaged and currently added to the backlog priority queue for further investigation. |
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
mshabarov
pushed a commit
that referenced
this issue
Nov 20, 2024
* fix: fix class and resource loading in maven plugin 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 * fix caching * fix class loading * updated dev-bundle plugin reflector * assert on URLs * fix regex * fix typo * apply review suggestions * fix typo
github-project-automation
bot
moved this from 🏗 WIP
to ✅ Closed
in Vaadin Flow bugs & maintenance (Vaadin 10+)
github-project-automation
bot
moved this from 🔎Iteration reviews
to Done
in Vaadin Flow ongoing work (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 the application class is used as AppShellConfigurator as in the starter project, the production build fails with
NoClassDefFoundError: org/springframework/context/ApplicationEventPublisherAwareif the application class is also annotated with@EnableJpaRepositories.This happens only with profile production, but fails in the
prepare-frontendgoal that is executed beforebuild-frontend.The exception itself comes probably from the fact that the AppShellConfigurator class (or any class that is annotated with @theme) is annotated with
@EnableJpaRepository, which importsJpaRepositoryFactoryBeanthat ultimately implementsApplicationEventPublisherAware. However, why the class cannot be found is not not clear to me. Its dependencyspring-contextis included in the compile scope.ApplicationEventPublisherAwarehas many implementations in Spring Security too.More detailed stacktrace:
Caused by: java.lang.TypeNotPresentException: Type [unknown] not present at java.lang.reflect.Method.getDefaultValue (Method.java:724) at sun.reflect.annotation.AnnotationType.<init> (AnnotationType.java:133) at sun.reflect.annotation.AnnotationType.getInstance (AnnotationType.java:85) at sun.reflect.annotation.AnnotationParser.parseAnnotation2 (AnnotationParser.java:262) at sun.reflect.annotation.AnnotationParser.parseAnnotations2 (AnnotationParser.java:121) at sun.reflect.annotation.AnnotationParser.parseAnnotations (AnnotationParser.java:73) at java.lang.Class.createAnnotationData (Class.java:4068) at java.lang.Class.annotationData (Class.java:4057) at java.lang.Class.getAnnotationsByType (Class.java:3965) at com.vaadin.flow.internal.AnnotationReader.getAnnotationsFor (AnnotationReader.java:221) at com.vaadin.flow.server.frontend.scanner.FullDependenciesScanner.lambda$verifyTheme$5 (FullDependenciesScanner.java:383) at java.util.stream.ReferencePipeline$7$1.accept (ReferencePipeline.java:273) at java.util.Iterator.forEachRemaining (Iterator.java:133) at java.util.Spliterators$IteratorSpliterator.forEachRemaining (Spliterators.java:1845) at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:509) at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:499) at java.util.stream.ReduceOps$ReduceOp.evaluateSequential (ReduceOps.java:921) at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.collect (ReferencePipeline.java:682) at com.vaadin.flow.server.frontend.scanner.FullDependenciesScanner.verifyTheme (FullDependenciesScanner.java:389) at com.vaadin.flow.server.frontend.scanner.FullDependenciesScanner.discoverTheme (FullDependenciesScanner.java:339) at com.vaadin.flow.server.frontend.scanner.FullDependenciesScanner.<init> (FullDependenciesScanner.java:131) at com.vaadin.flow.server.frontend.scanner.FullDependenciesScanner.<init> (FullDependenciesScanner.java:94) at com.vaadin.flow.server.frontend.scanner.FrontendDependenciesScanner$FrontendDependenciesScannerFactory.createScanner (FrontendDependenciesScanner.java:93) at com.vaadin.flow.server.frontend.NodeTasks.<init> (NodeTasks.java:125) at com.vaadin.flow.plugin.base.BuildFrontendUtil.prepareFrontend (BuildFrontendUtil.java:172) at com.vaadin.flow.plugin.maven.PrepareFrontendMojo.execute (PrepareFrontendMojo.java:64) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174) at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75) at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162) at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283) at org.apache.maven.cli.MavenCli.main (MavenCli.java:206) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:568) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:283) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:226) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:407) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:348) Caused by: java.lang.NoClassDefFoundError: org/springframework/context/ApplicationEventPublisherAware at java.lang.ClassLoader.defineClass1 (Native Method) at java.lang.ClassLoader.defineClass (ClassLoader.java:1012) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:150) at java.net.URLClassLoader.defineClass (URLClassLoader.java:524Expected behavior
No exception during production build.
Minimal reproducible example
Using the starter:
spring-data-jpaas dependencypublic class TestRepository implements Repository<String, Integer>{}. Can be a static inner class of the Application class@EnableJpaRepositories(basePackageClasses = Application.TestRepository.class)Execute
mvn clean package -Pproductionand see the build fail.Versions
The text was updated successfully, but these errors were encountered: