Repository navigation
feat: merge packages from multiple @EnableVaadin annotations - #26482
Conversation
Fixes #25022 Co-authored-by: Hariharan G <167274701+Hariharan02112004@users.noreply.github.com>
Type of change
Test coverage
|
vaadin-review-bot
left a comment
There was a problem hiding this comment.
Reviewed the changes — left 1 comment.
| Finding | |
|---|---|
| 📝 | The new javadoc about merging does not say that an annotation without packages contributes nothing and that the default application package is then dropped. |
| * If packages are not specified then default Spring Boot application | ||
| * package is used. | ||
| * <p> | ||
| * The annotation can be added to several configuration classes. The |
There was a problem hiding this comment.
📝 The new javadoc about merging does not say that an annotation without packages contributes nothing and that the default application package is then dropped.
The two paragraphs now read together as "no packages → default application package" plus "packages of all annotations are scanned". But the merge only covers annotations that declare packages, and getDefaultPackages falls back to the auto-configuration packages only when the merged list is empty.
So a @SpringBootApplication carrying a bare @EnableVaadin next to a module's @EnableVaadin("com.acme.a.views") scans only the module package, and routes in the application package silently stop being found. Worth spelling out, since "one annotation per module" is the pattern this PR promotes.
EnableVaadin.java:76 · documentation
There was a problem hiding this comment.
Documented in EnableVaadin (efb883d): an annotation without packages adds no packages, and the default application package must be listed explicitly when another annotation declares packages. This was already the behaviour before this PR.
|
Explain that applying @EnableVaadin to several configuration classes scans the packages of all of them, on the routing page's guidance for specifying Vaadin scan packages. Documents vaadin/flow#26482 (`efb883dc60ec5cb5853c9733800c72b408e5e2e8`).
|
Pull request created: #6479
|
|
Documentation Bot: Draft documentation pull request for this change: vaadin/docs#6479 Files updated:
It was written from the state of this pull request as you see it now. Please review it and mark it ready for review.
|
Explain that applying @EnableVaadin to several configuration classes scans the packages of all of them, on the routing page's guidance for specifying Vaadin scan packages. Documents vaadin/flow#26482 (`efb883dc60ec5cb5853c9733800c72b408e5e2e8`).
Documentation for vaadin/flow#26482 by `@mcollovati`. > [!NOTE] > The source pull request is merged, so this documentation describes the final > shape of the change. Please review it and mark it ready for review. **Change categories:** BEHAVIOR_CHANGE | File | Change | |------|--------| | articles/flow/integrations/spring/routing.adoc | Note that `@EnableVaadin` can be added to several configuration classes and that Vaadin scans the packages of all of them, instead of only describing a single annotation use. | Auto-generated by the Documentation Bot — review before merging. > Generated by [Documentation Bot](https://github.com/vaadin/flow/actions/runs/39951898666) for #26482 · agent · 87.5 AIC · ⊞ 11.7K · [◷](https://github.com/search?q=repo%3Avaadin%2Fdocs+%22gh-aw-workflow-id%3A+doc-bot%22&type=pullrequests) > - [x] expires <!-- gh-aw-expires: 2026-11-22T12:21:04.621Z --> on Nov 22, 2026, 12:21 PM UTC <!-- gh-aw-agentic-workflow: Documentation Bot, engine: claude, model: agent, id: 39951898666, workflow_id: doc-bot, run: https://github.com/vaadin/flow/actions/runs/39951898666 --> <!-- gh-aw-expires-type: pull-request --> <!-- gh-aw-workflow-id: doc-bot --> <!-- gh-aw-workflow-call-id: vaadin/flow/doc-bot -->



Fixes #25022
new feature · vaadin-spring · Spring apps with
@EnableVaadinonmore than one configuration class
Applications can now put
@EnableVaadinwith packages on severalconfiguration classes, for example one per module, and Vaadin scans the
packages of all of them. Before, a Spring Boot application failed at
startup with
BeanDefinitionOverrideException, and plain Spring keptonly the packages of the last annotation.
Risks:
@EnableVaadinannotations now scan all their packages, not only thepackages of the last annotation processed
✅ No public API, security, memory, serialization, threading,
performance or migration impact
Changed
VaadinScanPackagesRegistrarto add the packages of each@EnableVaadinto the bean definition that is already registered,instead of registering a second one
Turned
VaadinScanPackagesinto a package-private record that holdsan unmodifiable list
Documented in
EnableVaadinthat packages from several annotationsare merged
Added
VaadinScanPackagesRegistrarTest, which runs with beandefinition overriding disabled, as in Spring Boot
Based on Make VaadinScanPackages serializable and merge scan packages correctly #25062 by @Hariharan02112004