Woche 1, Tag 5 — Component Scanning und Package-Struktur

Ziel

Heute verstehst du, wie Spring deine Klassen findet und als Beans registriert.

Die Kernfragen:

1. Was ist Component Scanning?
2. Was macht @ComponentScan?
3. Was scannt @SpringBootApplication standardmäßig?
4. Warum ist die Package-Struktur wichtig?
5. Warum wird eine Klasse mit @Service trotzdem keine Bean?
6. Wie passt man Component Scanning an?
7. Was sind Stereotyp-Annotationen?
8. Welche typischen Bugs gibt es beim Component Scanning?
9. Welche Prüfungsfallen gibt es?

---

1. Kurz-Wiederholung

Aus den bisherigen Tagen:

• Eine Spring Bean ist ein von Spring verwaltetes Objekt.
• Spring muss wissen, welche Klassen Beans werden sollen.
• Beans registrierst du mit @Component, @Service, @Repository, @Controller, @RestController oder @Bean.
• ApplicationContext speichert und verwaltet Beans.
• BeanDefinition sind Metadaten zur Bean-Erzeugung.

Heute die Frage:

Wie findet Spring meine annotierten Klassen?

Die Antwort:

Component Scanning.

---

2. Was ist Component Scanning?

Component Scanning heißt:

Spring durchsucht Packages nach Klassen mit Spring-Stereotyp-Annotationen und registriert sie als Beans.

Beispiel:

@Service
public class OrderService {
}

Diese Klasse wird nur dann eine Bean, wenn Spring das Package scannt, in dem sie liegt.

Wichtig:

Die Annotation allein reicht nicht. Die Klasse muss im Component-Scan-Pfad liegen.

---

3. Wonach sucht Spring?

Beim Component Scanning sucht Spring nach Annotationen wie:

@Component
@Service
@Repository
@Controller
@RestController
@Configuration

Das sind Stereotyp-Annotationen.

Findet Spring eine davon, kann sie eine BeanDefinition registrieren.

Später erzeugt Spring die eigentliche Bean.

---

4. Ablauf beim Component Scanning

Vereinfachter Ablauf:

1. Spring-App startet.
2. ApplicationContext wird erstellt.
3. Spring prüft das Basis-Package für den Scan.
4. Spring scannt Klassen in diesem Package und Unterpackages.
5. Spring findet Annotationen wie @Service und @Repository.
6. Spring registriert BeanDefinitions.
7. Spring erzeugt Beans.
8. Spring injiziert Abhängigkeiten.

Merksatz:

Component Scanning findet Klassen. Bean-Erzeugung macht Objekte daraus.

---

5. @ComponentScan

Die Annotation für das Scannen:

@ComponentScan

Beispiel:

@Configuration
@ComponentScan("com.example.app")
public class AppConfig {
}

Das sagt Spring:

Scanne com.example.app und alle Unterpackages.

Also:

com.example.app
com.example.app.service
com.example.app.repository
com.example.app.controller

---

6. Spring Boot und @SpringBootApplication

In Spring Boot schreibst du @ComponentScan meist nicht direkt.

Stattdessen:

@SpringBootApplication
public class MyApplication {
}

@SpringBootApplication enthält bereits:

@Configuration
@EnableAutoConfiguration
@ComponentScan

Wichtig für die Prüfung:

@SpringBootApplication enthält @ComponentScan.

---

7. Standard-Scan-Package in Spring Boot

Spring Boot startet den Scan im Package der Hauptanwendungsklasse.

Beispiel:

package com.example.kanzlei;

@SpringBootApplication
public class KanzleiApplication {
}

Spring scannt:

com.example.kanzlei
com.example.kanzlei.controller
com.example.kanzlei.service
com.example.kanzlei.repository
com.example.kanzlei.config

Hauptpackage und alle Unterpackages.

---

8. Gute Package-Struktur

Gute Struktur:

com.example.kanzlei
├── KanzleiApplication.java
├── controller
│   └── TaskController.java
├── service
│   └── TaskService.java
├── repository
│   └── TaskRepository.java
├── entity
│   └── Task.java
├── dto
│   └── TaskResponse.java
└── config
    └── SecurityConfig.java

Gut, weil die Hauptklasse im Root-Package liegt:

com.example.kanzlei

Alle anderen Klassen darunter.

Spring kann alles scannen.

---

9. Schlechte Package-Struktur

Schlechte Struktur:

com.example.app
└── KanzleiApplication.java

com.example.service
└── TaskService.java

com.example.repository
└── TaskRepository.java

Liegt die Hauptklasse in:

com.example.app

scannt Spring:

com.example.app

Aber nicht automatisch:

com.example.service
com.example.repository

TaskService und TaskRepository werden dann vielleicht keine Beans.

---

10. Echter Bug

Diese Klasse existiert:

package com.example.service;

@Service
public class TaskService {
}

Hauptklasse:

package com.example.app;

@SpringBootApplication
public class MyApplication {
}

Spring scannt:

com.example.app

TaskService liegt in:

com.example.service

Ergebnis:

TaskService wird nicht gefunden.
TaskService wird nicht als Bean registriert.
App schlägt vielleicht fehl mit "No qualifying bean of type TaskService".

---

11. Best Practice

Hauptanwendungsklasse ins Root-Package legen.

Gut:

com.steve.klarsync
├── KlarsyncApplication.java
├── task
├── user
├── client
├── document
└── config

Schlecht:

com.steve.klarsync.app
└── KlarsyncApplication.java

com.steve.klarsync.task
com.steve.klarsync.user
com.steve.klarsync.client

Warum schlecht?

com.steve.klarsync.task liegt nicht unter com.steve.klarsync.app.

---

12. Einfache Regel

Die Spring-Boot-Hauptklasse gehört ins höchste/Root-Package der Anwendung.

Beispiel:

package de.klarsync;

@SpringBootApplication
public class KlarsyncApplication {
}

Dann die anderen Packages darunter:

de.klarsync.task
de.klarsync.user
de.klarsync.client
de.klarsync.security
de.klarsync.config

---

13. Stereotyp-Annotationen

Diese Annotationen signalisieren die Rolle einer Klasse.

@Component

Generische Spring-verwaltete Komponente.

@Component
public class SlugGenerator {
}

Wenn die Klasse nicht klar Service-, Repository- oder Controller-Layer ist.

---

@Service

Business-Logik-Layer.

@Service
public class TaskService {
}

Für Application Services und Domain-Use-Cases.

---

@Repository

Persistence-Layer.

@Repository
public class JdbcTaskRepository {
}

Für Klassen mit Datenbankzugriff.

Besonderheit:

@Repository kann Persistence Exception Translation aktivieren.

---

@Controller

Spring-MVC-Controller für Views.

@Controller
public class HomeController {
}

Für serverseitig gerenderte HTML-Seiten.

---

@RestController

REST-API-Controller.

@RestController
@RequestMapping("/api/tasks")
public class TaskController {
}

@RestController enthält:

@Controller
@ResponseBody

---

@Configuration

Konfigurationsklasse.

@Configuration
public class AppConfig {
}

Oft mit @Bean-Methoden.

---

14. Wichtig: @Configuration ist auch eine Component

@Configuration wird auch per Component Scanning gefunden.

Beispiel:

@Configuration
public class TimeConfig {

    @Bean
    public Clock clock() {
        return Clock.systemUTC();
    }
}

Liegt TimeConfig im Scan-Pfad, findet Spring sie.

Dann verarbeitet Spring die @Bean-Methode und registriert Clock als Bean.

---

15. @Bean braucht registrierte Konfigurationsklasse

Beispiel:

@Configuration
public class TimeConfig {

    @Bean
    public Clock clock() {
        return Clock.systemUTC();
    }
}

Funktioniert, wenn TimeConfig per Component Scanning gefunden wird.

Liegt TimeConfig außerhalb des Scan-Pfads, findet Spring sie nicht.

Dann wird die clock-Bean nicht registriert.

Prüfungsfalle:

@Bean-Methoden werden nur verarbeitet, wenn die Konfigurationsklasse selbst registriert ist.

---

16. Component Scanning anpassen

Du kannst Scan-Packages explizit setzen.

Beispiel:

@SpringBootApplication(scanBasePackages = "com.example")
public class MyApplication {
}

Spring scannt:

com.example

Alternativ:

@Configuration
@ComponentScan(basePackages = "com.example")
public class AppConfig {
}

---

17. Mehrere Basis-Packages

Mehrere Packages scannen:

@SpringBootApplication(scanBasePackages = {
    "com.example.app",
    "com.example.shared"
})
public class MyApplication {
}

Oder:

@ComponentScan(basePackages = {
    "com.example.app",
    "com.example.shared"
})

Best Practice bleibt:

Hauptklasse ins Root-Package — Custom-Scan nur wenn nötig.

---

18. Typsichere Alternative: basePackageClasses

Statt Package-Namen als Strings kannst du Klassen nutzen.

Beispiel:

@ComponentScan(basePackageClasses = {
    TaskService.class,
    SharedConfig.class
})
public class AppConfig {
}

Sicherer — beim Refactoring der Klassen-Packages musst du keine String-Namen manuell anpassen.

---

19. Include- und Exclude-Filter

@ComponentScan kann Klassen ein- oder ausschließen.

Beispiel:

@ComponentScan(
    basePackages = "com.example",
    excludeFilters = @ComponentScan.Filter(
        type = FilterType.ANNOTATION,
        classes = Deprecated.class
    )
)

Fortgeschritten.

Für die Zertifizierung: Component Scanning ist anpassbar — die meisten Fragen betreffen den Standard-Scan.

---

20. Warum wird mein Service nicht injiziert?

Beispiel-Fehler:

Parameter 0 of constructor in TaskController required a bean of type 'TaskService' that could not be found.

Mögliche Gründe:

1. TaskService hat kein @Service, @Component oder @Bean.
2. TaskService liegt außerhalb des gescannten Packages.
3. TaskService hat ein Profil, das nicht aktiv ist.
4. TaskService ist conditional und die Bedingung ist false.
5. TaskService kann nicht erzeugt werden — fehlende Abhängigkeit.
6. Falsche Klasse oder falsches Package importiert.
7. Der Test-Slice lädt diese Bean nicht.

Am häufigsten:

Fehlende Annotation
Außerhalb des Component Scans
Fehlende Abhängigkeit

---

21. Erzeugt @Service immer eine Bean?

Nein.

Diese Klasse:

@Service
public class TaskService {
}

wird nur dann eine Bean, wenn Spring ihr Package scannt.

Richtige Antwort:

@Service markiert die Klasse als Kandidat für Component Scanning. Sie wird nur dann eine Bean, wenn der Scan sie findet.

---

22. Scannt @ComponentScan das ganze Projekt?

Nein.

Standardmäßig scannt es von einem Basis-Package aus.

In Spring Boot ist das meist das Package der Klasse mit @SpringBootApplication.

Nicht automatisch der gesamte Quellcode.

---

23. Scannt Spring externe Libraries?

Nicht automatisch auf dieselbe Weise.

Spring scannt konfigurierte Basis-Packages.

Spring Boot Auto-Konfiguration kann Beans aus Libraries über einen anderen Mechanismus registrieren.

Wichtige Unterscheidung:

Component Scanning findet meine annotierten Klassen.
Auto-Konfiguration registriert Framework-/Library-Beans per Bedingungen.

Beispiel:

• Mein TaskService wird per Component Scanning gefunden.
• Spring Boot erzeugt DispatcherServlet per Auto-Konfiguration.

---

24. Component Scanning vs. Auto-Konfiguration

Thema	Component Scanning	Auto-Konfiguration
Zweck	Meine Klassen finden	Spring-Boot-Infrastruktur einrichten
Basis	Packages und Annotationen	Classpath, Properties, Bedingungen
Beispiel	@Service TaskService	Embedded Tomcat, DispatcherServlet
Annotation	@ComponentScan	@EnableAutoConfiguration
Enthalten in	@SpringBootApplication	@SpringBootApplication

Merksatz:

Component Scanning findet meine Beans. Auto-Konfiguration erzeugt Spring-Boot-Infrastruktur-Beans.

---

25. Component Scanning vs. @Bean

Thema	Component Scanning	@Bean
Wie registriert?	Spring findet annotierte Klasse	Methoden-Rückgabewert wird Bean
Am besten für	Eigene Klassen	Drittanbieter/Custom-Objekte
Beispiel	@Service TaskService	@Bean Clock
Scan nötig?	Klasse muss gescannt werden	Config-Klasse muss registriert sein

---

26. Component Scanning und Tests

Manchmal funktioniert eine Bean in der echten App, aber nicht im Test.

Beispiel:

@WebMvcTest(TaskController.class)
class TaskControllerTest {
}

Dieser Test lädt nur den Web-Layer.

Nicht alle Services.

Dann kann das fehlschlagen:

No qualifying bean of type TaskService

Fix:

@MockBean
private TaskService taskService;

Wichtig:

Test-Slice-Annotationen laden nur einen Teil des Application Context.

Kein reines Component-Scanning-Problem — sieht aber ähnlich aus.

---

27. Component Scanning und Profile

Eine Klasse kann gescannt, aber wegen eines Profils inaktiv sein.

Beispiel:

@Service
@Profile("prod")
public class RealEmailService {
}

Diese Bean wird nur erzeugt, wenn das Profil prod aktiv ist.

Ist dev aktiv, erzeugt Spring sie nicht.

---

28. Component Scanning und Conditional Beans

Eine Klasse kann conditional sein.

Beispiel:

@Component
@ConditionalOnProperty(name = "feature.audit.enabled", havingValue = "true")
public class AuditService {
}

Diese Bean wird nur erzeugt, wenn die Property passt.

Sonst überspringt Spring sie.

Häufig in Spring Boot.

---

29. Component Scanning und Bean-Namen

Standard-Bean-Name: Klassenname mit kleinem Anfangsbuchstaben.

Beispiel:

@Service
public class TaskService {
}

Bean-Name:

taskService

Beispiel:

@Component
public class EmailNotificationSender {
}

Bean-Name:

emailNotificationSender

Eigener Name:

@Service("mainTaskService")
public class TaskService {
}

Bean-Name:

mainTaskService

---

30. Component Scanning und Interfaces

Spring kann ein Interface nicht direkt instanziieren.

Beispiel:

public interface PaymentProvider {
}

Allein ist das keine Bean.

Spring braucht eine Implementierung:

@Component
public class StripePaymentProvider implements PaymentProvider {
}

Dann kann Spring per Interface-Typ injizieren:

@Service
public class CheckoutService {

    public CheckoutService(PaymentProvider paymentProvider) {
    }
}

Funktioniert bei genau einer Implementierungs-Bean.

---

31. Component Scanning und abstrakte Klassen

Spring kann abstrakte Klassen normalerweise nicht instanziieren.

Beispiel:

@Component
public abstract class BaseService {
}

Als normale Bean unbrauchbar — Spring kann keine abstrakte Instanz erzeugen.

Subklassen können aber Beans sein:

@Service
public class TaskService extends BaseService {
}

---

32. Component Scanning und innere Klassen

Spring scannt meist Top-Level-Klassen.

Statische Nested Classes können manchmal registriert werden — besonders in Config oder Tests. Normale App-Komponenten sollten Top-Level-Klassen sein.

Best Practice:

Spring-Komponenten als klare Top-Level-Klassen halten.

---

33. Component Scanning und final-Klassen

Eine final-Klasse kann als Bean registriert werden.

final kann aber problematisch sein, wenn Spring einen klassenbasierten Proxy braucht — z. B. für AOP oder Transaktionen.

Beispiel:

@Service
public final class PaymentService {
}

Die Bean kann erzeugt werden.

Proxying kann später zum Problem werden.

Proxies schauen wir in der AOP-Woche an.

---

34. Component Scanning und Kotlin

In Kotlin sind Klassen standardmäßig final.

Spring braucht oft offene Klassen für Proxying.

Deshalb nutzen Kotlin-Spring-Projekte oft:

kotlin("plugin.spring")

Das öffnet Spring-annotierte Klassen automatisch.

Prüfungsfokus ist meist Java — die Proxy-Idee ist aber wichtig.

---

35. Debug-Checkliste

Wenn eine Bean nicht gefunden wird:

## Bean nicht gefunden — Debug-Checkliste

[ ] Hat die Klasse `@Component`, `@Service`, `@Repository`, `@Controller`, `@RestController` oder wird sie per `@Bean` erzeugt?
[ ] Liegt die Klasse im von Spring gescannten Package?
[ ] Liegt die Hauptklasse im Root-Package?
[ ] Ist das aktive Profil korrekt?
[ ] Hat die Bean eine Bedingung, die false ist?
[ ] Sind alle Konstruktor-Abhängigkeiten verfügbar?
[ ] Nutze ich einen Test-Slice wie `@WebMvcTest` oder `@DataJpaTest`?
[ ] Habe ich das richtige Annotation-Package importiert?
[ ] Ist die Klasse konkret, nicht abstrakt?
[ ] Gibt es eine zirkuläre Abhängigkeit?

---

36. Prüfungsfrage: Package-Struktur

Frage:

package com.example.app;

@SpringBootApplication
public class MyApplication {
}

package com.example.service;

@Service
public class UserService {
}

Wird UserService automatisch gefunden?

Antwort:

Nein. Spring Boot scannt standardmäßig ab dem Package der Hauptklasse — com.example.app. UserService liegt in com.example.service, kein Unterpackage von com.example.app. Wird nicht gefunden, außer der Scan wird angepasst.

---

37. Prüfungsfrage: Gute Package-Struktur

Frage:

package com.example;

@SpringBootApplication
public class MyApplication {
}

package com.example.service;

@Service
public class UserService {
}

Wird UserService gefunden?

Antwort:

Ja. Die Hauptklasse liegt in com.example — Spring scannt com.example und Unterpackages. com.example.service ist ein Unterpackage, UserService kann gefunden werden.

---

38. Prüfungsfrage: @SpringBootApplication

Frage:

Welche drei Annotationen enthält @SpringBootApplication?

Antwort:

@Configuration
@EnableAutoConfiguration
@ComponentScan

---

39. Prüfungsfrage: @Service

Frage:

Garantiert @Service allein, dass eine Klasse Spring Bean wird?

Antwort:

Nein. @Service markiert die Klasse als Kandidat für Component Scanning. Sie wird nur dann eine Bean, wenn Component Scanning sie findet oder sie anders registriert wird.

---

40. Prüfungsfrage: @Bean

Frage:

@Configuration
public class AppConfig {

    @Bean
    public Clock clock() {
        return Clock.systemUTC();
    }
}

Was wird zur Bean?

Antwort:

Der Rückgabewert der clock()-Methode. Standard-Bean-Name: clock, Bean-Typ: Clock.

---

41. Prüfungsfrage: Config außerhalb des Scans

Frage:

Enthält AppConfig eine @Bean-Methode, liegt AppConfig aber außerhalb des Component Scans — wird die Bean erzeugt?

Antwort:

Nein, nicht automatisch. Die Konfigurationsklasse muss bei Spring registriert sein. Liegt sie außerhalb des Scans und wird nicht importiert oder anders registriert, verarbeitet Spring ihre @Bean-Methoden nicht.

---

42. Prüfungsfrage: Component-Scan-Basis-Package

Frage:

Wo startet Spring Boot standardmäßig den Component Scan?

Antwort:

Im Package der Klasse mit @SpringBootApplication — inklusive aller Unterpackages.

---

43. Prüfungsfrage: Custom Scan

Frage:

Wie sage ich Spring Boot, ein anderes Package zu scannen?

Antwort:

@SpringBootApplication(scanBasePackages = "com.example")
public class MyApplication {
}

oder:

@ComponentScan(basePackages = "com.example")

---

44. Prüfungsfrage: Component Scan vs. Auto-Konfiguration

Frage:

Unterschied Component Scanning und Auto-Konfiguration?

Antwort:

Component Scanning findet App-Klassen mit Stereotypen wie @Component, @Service, @Repository. Auto-Konfiguration erzeugt Spring-Boot-Infrastruktur-Beans per Classpath, Properties, vorhandenen Beans und Bedingungen. Component Scanning = meine App-Beans. Auto-Konfiguration = Boot-Setup.

---

45. Prüfungsfrage: Bean nicht gefunden

Frage:

Typische Gründe für diesen Fehler?

No qualifying bean of type 'EmailService' available

Antwort:

EmailService nicht annotiert oder per @Bean registriert, außerhalb des Scan-Pfads, falsches Profil, Bedingung verhindert Erzeugung, fehlende Abhängigkeit, oder der aktuelle Test-Slice lädt die Bean nicht.

---

46. Interview-Antwort

Frage:

Was ist Component Scanning in Spring?

Gute Antwort:

Component Scanning ist der Prozess, bei dem Spring konfigurierte Packages nach Klassen mit Stereotyp-Annotationen wie @Component, @Service, @Repository und @Controller durchsucht. Gefundene Klassen werden als Bean-Definitionen registriert und später als Beans erzeugt. In Spring Boot aktiviert @SpringBootApplication den Scan — es enthält @ComponentScan. Standardmäßig scannt Spring Boot ab dem Package der Hauptklasse und allen Unterpackages.

---

47. Interview-Antwort

Frage:

Warum soll die Spring-Boot-Hauptklasse ins Root-Package?

Gute Antwort:

Spring Boot startet den Component Scan im Package der Klasse mit @SpringBootApplication. Liegt die Hauptklasse zu tief, werden Services, Repositories, Controller oder Config-Klassen in Geschwister-Packages vielleicht nicht gescannt. Im Root-Package werden alle Unterpackages automatisch erfasst.

---

48. Interview-Antwort

Frage:

Warum wird eine Klasse mit @Service trotzdem nicht gefunden?

Gute Antwort:

Vielleicht liegt sie außerhalb des Component-Scan-Pfads. @Service markiert sie nur als Kandidat — Spring muss ihr Package scannen. Weitere Gründe: falsches Profil, Conditional-Annotationen, fehlende Konstruktor-Abhängigkeiten oder Test-Slices, die nicht den vollen Context laden.

---

49. Interview-Antwort

Frage:

Unterschied Component Scanning und @Bean-Registrierung?

Gute Antwort:

Component Scanning registriert Beans, indem es Klassen mit Stereotypen wie @Component, @Service oder @Repository findet — meist für eigene App-Klassen. @Bean-Registrierung: Spring ruft eine Methode in einer Konfigurationsklasse auf und registriert den Rückgabewert als Bean. Nützlich für Drittanbieter-Objekte oder eigene Erzeugungslogik.

---

50. Kleines Code-Übungsbeispiel

Erstelle diese Struktur:

de.klarsync
├── KlarsyncApplication.java
├── task
│   ├── TaskController.java
│   └── TaskService.java
└── config
    └── TimeConfig.java

Hauptklasse:

package de.klarsync;

@SpringBootApplication
public class KlarsyncApplication {

    public static void main(String[] args) {
        SpringApplication.run(KlarsyncApplication.class, args);
    }
}

Service:

package de.klarsync.task;

@Service
public class TaskService {
}

Config:

package de.klarsync.config;

@Configuration
public class TimeConfig {

    @Bean
    public Clock clock() {
        return Clock.systemUTC();
    }
}

Frage:

Werden TaskService und Clock als Beans registriert?

Antwort:

Ja. KlarsyncApplication liegt in de.klarsync — Spring scannt de.klarsync und alle Unterpackages. Er findet TaskService in de.klarsync.task und TimeConfig in de.klarsync.config. Dann verarbeitet er die @Bean-Methode und erzeugt die Clock-Bean.

---

51. Bug-Übungsbeispiel

Schlechte Struktur:

de.klarsync.app
└── KlarsyncApplication.java

de.klarsync.task
└── TaskService.java

Hauptklasse:

package de.klarsync.app;

@SpringBootApplication
public class KlarsyncApplication {
}

Service:

package de.klarsync.task;

@Service
public class TaskService {
}

Frage:

Wird TaskService gefunden?

Antwort:

Nein. Spring scannt ab de.klarsync.app. de.klarsync.task ist kein Unterpackage davon — TaskService liegt außerhalb des Standard-Scan-Pfads.

Mögliche Fixes:

1. Hauptklasse nach de.klarsync verschieben.
2. scanBasePackages = "de.klarsync" nutzen.
3. Explizites @ComponentScan.

Bester Fix:

Hauptklasse ins Root-Package verschieben.

---

Übungsfragen

Frage 1

Was ist Component Scanning?

Antwort:

Spring durchsucht konfigurierte Packages nach Klassen mit Stereotyp-Annotationen wie @Component, @Service, @Repository, @Controller. Diese werden als Bean-Definitionen registriert und später als Beans erzeugt.

---

Frage 2

Welche Annotation aktiviert Component Scanning?

Antwort:

@ComponentScan.

---

Frage 3

Enthält @SpringBootApplication @ComponentScan?

Antwort:

Ja — zusammen mit @Configuration und @EnableAutoConfiguration.

---

Frage 4

Wo startet Spring Boot standardmäßig den Scan?

Antwort:

Im Package der Klasse mit @SpringBootApplication — inklusive Unterpackages.

---

Frage 5

Warum soll die Spring-Boot-Hauptklasse im Root-Package liegen?

Antwort:

Damit Spring alle App-Unterpackages automatisch scannt. Liegt die Hauptklasse zu tief, werden Geschwister-Packages vielleicht nicht erfasst.

---

Frage 6

Garantiert @Service immer eine Bean?

Antwort:

Nein. @Service markiert nur einen Scan-Kandidaten. Bean wird sie nur, wenn Spring ihr Package scannt oder sie anders registriert wird.

---

Frage 7

Was sind Stereotyp-Annotationen?

Antwort:

Annotationen, die eine Klasse als Spring-verwaltete Komponente markieren und ihre Rolle signalisieren — Service, Repository, Controller usw.

---

Frage 8

Nenne fünf Stereotyp-Annotationen.

Antwort:

@Component
@Service
@Repository
@Controller
@RestController

Auch wichtig:

@Configuration

---

Frage 9

Unterschied @Component und @Service?

Antwort:

@Component ist generisch. @Service ist eine Spezialisierung für Service-Layer-Klassen mit Business-Logik.

---

Frage 10

Was ist besonders an @Repository?

Antwort:

Markiert Persistence-Layer-Klassen und kann Persistence Exception Translation in Springs DataAccessException-Hierarchie aktivieren.

---

Frage 11

Was enthält @RestController?

Antwort:

@Controller und @ResponseBody.

---

Frage 12

Unterschied Component Scanning und @Bean?

Antwort:

Component Scanning findet annotierte Klassen. @Bean registriert den Rückgabewert einer Methode in einer Konfigurationsklasse. Scanning für eigene Klassen, @Bean für Drittanbieter oder Custom-Erzeugung.

---

Frage 13

Was muss passieren, damit eine @Bean-Methode verarbeitet wird?

Antwort:

Die Konfigurationsklasse muss bei Spring registriert sein — meist per Component Scanning, @Import oder direkter Config-Registrierung.

---

Frage 14

Standard-Bean-Name für diese Klasse?

@Service
public class EmailService {
}

Antwort:

emailService

---

Frage 15

Wird dieser Service gescannt?

package com.example.app;

@SpringBootApplication
public class MyApplication {
}

package com.example.app.service;

@Service
public class UserService {
}

Antwort:

Ja. UserService liegt in com.example.app.service — Unterpackage von com.example.app.

---

Frage 16

Wird dieser Service gescannt?

package com.example.app;

@SpringBootApplication
public class MyApplication {
}

package com.example.service;

@Service
public class UserService {
}

Antwort:

Nein. com.example.service ist kein Unterpackage von com.example.app — außerhalb des Standard-Scan-Pfads.

---

Frage 17

Wie passe ich das Scan-Basis-Package an?

Antwort:

@SpringBootApplication(scanBasePackages = "com.example")

oder:

@ComponentScan(basePackages = "com.example")

---

Frage 18

Unterschied Component Scanning und Auto-Konfiguration?

Antwort:

Component Scanning findet App-Klassen mit Stereotypen. Auto-Konfiguration erzeugt Spring-Boot-Infrastruktur-Beans per Classpath, Properties, vorhandenen Beans und Bedingungen.

---

Frage 19

Warum wird eine Bean mit @Service trotzdem nicht gefunden?

Antwort:

Mögliche Gründe: außerhalb des Component Scans, falsches Profil, false-Bedingung, fehlende Konstruktor-Abhängigkeit, Test-Slice lädt die Bean nicht, falscher Import, Klasse nicht instanziierbar.

---

Frage 20

Was prüfe ich bei No qualifying bean of type ... available?

Antwort:

Annotation, Scan-Pfad, Position der Hauptklasse, aktives Profil, Bedingungen, Konstruktor-Abhängigkeiten, Test-Slice-Konfiguration, korrekte Imports, ob die Klasse konkret ist.

Merksätze zum Mitnehmen

• Component Scanning findet annotierte Klassen und registriert sie als Beans.
• @ComponentScan aktiviert Component Scanning.
• @SpringBootApplication enthält @ComponentScan.
• Spring Boot scannt standardmäßig ab dem Package der Hauptklasse.
• Die Hauptklasse gehört ins Root-Package.
• @Service ist nur ein Kandidat — Spring muss scannen.
• @Configuration-Klassen müssen registriert sein, damit @Bean-Methoden laufen.
• Component Scanning findet meine App-Beans.
• Auto-Konfiguration erzeugt Spring-Boot-Infrastruktur-Beans.
• @Component ist generisch.
• @Service = Business-Logik.
• @Repository = Persistence + Exception Translation.
• @RestController = @Controller + @ResponseBody.
• Bean-nicht-gefunden-Fehler: oft fehlende Annotation, falsches Package, inaktives Profil, false-Bedingung oder fehlende Abhängigkeit.