What are ghost beans and can I trust the detection? #26
|
The report has a ghostCandidates section listing some of my beans. Does this mean those beans are dead code I can delete? |
Replies: 1 comment
|
No — never delete based on the list alone. The wording is deliberate: WireDoctor never claims a bean is "unused", and every payload carries Ghost detection works in two phases with different trust postures: Phase 1 — Ghost Candidates (passive, always on): crosses three metadata signals with zero intrusion:
Detection errs broad on purpose — a false entry-point match just shrinks the candidate list, while a missed one would wrongly accuse a working bean. The Phase 2 — First-Touch Tracking (opt-in, dev/staging): wraps beans in a thin counting proxy and reports which were never invoked during this run ( Treat candidates as investigation leads: check for |
No — never delete based on the list alone. The wording is deliberate: WireDoctor never claims a bean is "unused", and every payload carries
confidence: LOWplus a disclaimer.Ghost detection works in two phases with different trust postures:
Phase 1 — Ghost Candidates (passive, always on): crosses three metadata signals with zero intrusion:
@Controller/@RestController,@Scheduled/@EventListener(incl. private/inherited methods), messaging listeners (@KafkaListeneretc.),CommandLineRunner,Lifecycle,HealthIndicator,@Configuration,@Aspect, …