Component scanning
Spring Concepts / Component scanning
Scanning discovers eligible bean classes in selected packages.
Understand the idea
In Stage 17, DeliveryInfoService supplies delivery time and charges to the product-details page. Application is in com.edupoly.lesson; its default scan misses the sibling com.edupoly.delivery package. A Java import permits a type reference but does not register a bean. @Service marks the class as eligible; scanBasePackages includes both packages so Spring discovers it, registers its bean definition and injects its reference into ProductController at startup. In Stage 18, DeliveryScanConfig excludes DemoDeliveryController from its delivery-package scan. The class still compiles, but no demo controller bean or route is registered by that scan. The real delivery service remains available. Keep other scans from independently registering the excluded type. Use exclusions for targeted omissions within a needed package; separate demo packages, profiles or property conditions may express other requirements more clearly.
A concrete example
@SpringBootApplication(scanBasePackages = {"com.edupoly.lesson", "com.edupoly.delivery"})In the application
See the independently runnable examples in Stage 17, Stage 18.
Having a Java class on the classpath does not automatically make its instances beans.
When a scan exclusion is useful
Use an exclusion when a package contains needed components alongside a particular component this application should not register. Examples include shared modules with demo controllers, temporary legacy replacements and application-specific selections from a shared package.
For Stage 18, keep DeliveryInfoService and exclude DemoDeliveryController. The demo Java class still compiles, but the filtered scan contributes no controller bean or demo route.
If we control the layout, putting demo code outside the normal scan may be simpler. Profiles express environment choices; Boot property conditions express feature switches. Exclusions are not needed routinely.