Production build fails if Spring Boot Application implements AppShellConfigurator and is annotated with a Spring Data JPA Repository #19616
Assignees
Labels
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 |
|
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
…#19724) Wraps the annotation finder function to log potential errors during class scanning and the class that originates the failure. References #19616 Co-authored-by: Marco Collovati <[email protected]>
vaadin-bot
added a commit
that referenced
this issue
Jul 26, 2024
…#19725) Wraps the annotation finder function to log potential errors during class scanning and the class that originates the failure. References #19616 Co-authored-by: Marco Collovati <[email protected]>
|
Just as a short info: So hopefully a fix will come in near future :) |
|
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. |
|
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
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: