-
Notifications
You must be signed in to change notification settings - Fork 220
fix(devloop): restart for a new Spring bean or entity the running app never had #25595
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
Merged
Merged
Changes from all commits
Commits
Show all changes
17 commits
Select commit
Hold shift + click to select a range
8ed7962
fix(devloop): restart for a Spring bean the running context never saw
totally-not-ai[bot] 25509e0
docs(devloop): record the new-bean escalation in the daemon README
totally-not-ai[bot] 9685bd3
fix(devloop): decide a new bean from the inventory, not from what is …
totally-not-ai[bot] eab199b
test(devloop): unit-test the decision and the reply the connector sends
totally-not-ai[bot] 0893610
test(devloop): pin what inspect reads off the loaded class
totally-not-ai[bot] 22a02c1
Merge remote-tracking branch 'origin/main' into issues/25559-new-spri…
totally-not-ai[bot] 5ce2661
refactor(devloop): name the source suffix, and hoist the descriptor l…
totally-not-ai[bot] a7a1a80
docs(devloop): link the stereotype list rather than pointing at it
totally-not-ai[bot] e88dd24
test(devloop): say why the new-bean fixture touches no loaded class
totally-not-ai[bot] d3ab425
test(devloop): cover @Component as well as @Service for a new bean
totally-not-ai[bot] dcfb4b3
test(devloop): assert every stereotype descriptor, not two of them
totally-not-ai[bot] 74ac99d
fix(devloop): a new bean the inventory was seeded with is still new
totally-not-ai[bot] 168a502
fix(devloop): take the baseline when the app registers, not on first …
totally-not-ai[bot] 1536984
fix(devloop): read the baseline against the launch, not against the c…
totally-not-ai[bot] 53830e3
fix(devloop): ask per class and by binary name, not per source and by…
totally-not-ai[bot] a8ee6d3
fix(devloop): snapshot what the launch had, rather than dating class …
totally-not-ai[bot] 9bb071d
Merge branch 'main' into issues/25559-new-spring-bean-restart
tltv File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found three issues:
[P1] Compile.java:844 treats a known source file as proof that every class it declares existed at startup. Adding a nested static
@Component, or another package-private top-level component, to an existing source therefore produces nounknownTypesentry. The connector reports the new class’s stereotype, butblockedReasondoes not restart, leaving the bean unregistered—the core failure this PR intends to fix.[P1] Compile.java:870 updates the same
appliedmap used as the startup inventory after successful hot swaps. Sequence: add a plain class → apply successfully → annotate it with@Component→ apply again. The first apply inserts its source intoapplied; the second considers the class known even though component scanning has never seen it, so no restart occurs.[P2] Compile.java:814 and TransactionEngine.java:1662 correlate classes by simple name. If an existing stereotype and a newly added plain class share a name in different packages, editing both in one transaction falsely reports the plain class as a new Spring bean and forces an unnecessary restart. Binary names are needed to preserve identity.
Also take care of the remaining 2 Sonar findings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tltv All three fixed, with a test each, and the two Sonar findings with them.
P1, per-source answer. Right — and the fix is to stop asking about sources. The question is now asked of each class the apply compiled, against the class files its output packages held before it compiled them: a class file that was not there, or that is newer than the launch, is one the application started without. A second top-level
@Componentin a file the application has always had now escalates under its own name.One thing worth recording from testing it: a nested
@Componentescalates on this JVM for an unrelated reason — nesting rewrites the enclosing class'sNestMembersattribute andredefineClassesrefuses outright (class redefinition failed: attempted to change the class NestHost, NestMembers...). So the test uses a second top-level class, which leaves the enclosing class byte-identical and actually exercises this rule rather than the JVM's refusal. The nested case is covered too, by the same per-class read.P1,
applieddoubling as the startup inventory. Same root, same fix: the class file an earlier apply wrote is newer than the launch, so add-plain-class → apply → annotate → apply now escalates on the second apply. There is an integration test for exactly that sequence.P2, simple-name correlation. Agreed, it was an identity bug.
stereotypes=now carries binary names — alone among the reply's fields, because it is the one read by machine rather than by a person, and the daemon matches the change-set against it exactly. Only the reason shortens the name again, so the message still readsnew Spring bean (Extra). The unit test pins that a stereotype sharing a simple name with a new class in another package escalates nothing.Sonar. The class-file read no longer swallows an
IOException: an unreadable output directory is not a state to decide a verdict from, so the apply fails with that as its reason. And the protocol's free-text tail is a constant.Green: 149 daemon and 346
vaadin-dev-serverunit tests, and 38 dev-loop ITs — the exception beingDevLoopBrowserIT.siblingModuleEdit_isVisibleOnceTheViewRendersAgain, which times out on my machine identically at the commit before any of this work, so it is not from these changes.Re-measured end to end on the reported flow (
start, add a class with a bare@Component,apply) and on the variant where something else compiles the class first: bothtx#1 classification=restart, escalating with the named reason.