DI-Problem in Spring Boot

[walk]

Hallo zusammen,

ich habe eine Spring Boot Applikation und scheitere beim Starten der App an folgender Exception:

***************************
APPLICATION FAILED TO START
***************************

Description:

Parameter 0 of method UserDTO in .configuration.UserConfiguration required a bean of type 'java.math.BigDecimal' that could not be found.


Action:

Consider defining a bean of type 'java.math.BigDecimal' in your configuration.

Quellcode:

import lombok.NoArgsConstructor;
import org.springframework.beans.factory.config.BeanDefinition;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Scope;

import java.math.BigDecimal;

@Configuration
public class UserConfiguration {

    @Bean
    @Scope(BeanDefinition.SCOPE_PROTOTYPE)
    public UserDTO userDTO(BigDecimal value, String name){
        return new UserDTO(value, name);
    }
}

Korrespondierende UserDTO

import java.math.BigDecimal;

import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;
import org.springframework.lang.Nullable;

import javax.validation.constraints.NotNull;

@Data
@Builder
@AllArgsConstructor
public class UserDTO {
    @NotNull
    private BigDecimal value;
    @NotNull
    private String name;

Ich hatte dieses DTO auch mit @Component annotiert und @AllArgsConstructor entfernt (Also wie im Beispiel unten zu UserRequestDTO), ohne Erfolg. Interessanterweise funktioniert es mit einem anderen DTO in dem auch UserDTO liegt, problemlos:

import java.util.List;

import javax.validation.constraints.NotNull;

import lombok.Builder;
import lombok.Data;
import org.springframework.stereotype.Component;

@Data
@Builder
@Component
public class UserRequestDTO {

    @NotNull
    private List<String> codes;
}

In UserRequestDTO genügt die @Component-Annotation, ich benötige nichtmal eine Konfigurationsklasse. Ich hatte auch schon probiert die Annotation nur in UserDTO anzugeben, ebenso ohne Erfolg.

Projektstruktur:

com.test.api
├── configuration
│ ├── UserConfiguration.java
│
├── dto
│ ├── UserDTO.java
│ ├── UserRequestDTO.java
├── Application.java

Dependencies:

plugins {
    id 'org.springframework.boot' version '2.7.3'
    id 'io.spring.dependency-management' version '1.0.13.RELEASE'
    id 'java'
}

dependencies {

    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'com.google.code.findbugs:jsr305:3.0.2'

    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'

    implementation "io.springfox:springfox-boot-starter:3.0.0"
    implementation 'javax.validation:validation-api:2.0.1.Final'
    implementation "com.h2database:h2:1.4.200"

    testImplementation('org.springframework.boot:spring-boot-starter-test') {
        exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
    }
}

 

[thecain]

Wie stellst du dir denn vor wie das funktionieren soll? Woher sollte der Wert für BigDecimal und Name kommen?

Und warum willst du das dein Dto ein Bean ist?

 

[walk]

Wie stellst du dir denn vor wie das funktionieren soll? Woher sollte der Wert für BigDecimal und Name kommen?

Das schlimme ist, ich wusste ab einem gewissen Zeitpunkt selbst nicht mehr was ich tue. Ich bin relativ neu in Spring und arbeite zum ersten Mal mit Lombok.

Ich werde nochmal die Grundlagen durchackern müssen.

Folgendes funktioniert:

import java.math.BigDecimal;

import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;
import org.springframework.lang.Nullable;

import javax.validation.constraints.NotNull;

@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
@Component
public class UserDTO {
    @NotNull
    private BigDecimal value;
    @NotNull
    private String name;
}

 

[thecain]

Ja, weil ein Noargs Constructor vorhanden ist und dani der @Component Annotation das Dto ein Bean ist.

Und "funktioniert" heisst wohl auch nur "kompiliert". Ich sehe keinen Grund warum dein DTO ein Besn sein müsste.

Ich werde nochmal die Grundlagen durchackern müssen.

Ist eine gute Idee. Vielleicht sogar im ersten Schritt noch auf Lombok verzichten.

 

[KonradN]

Evtl. einfach einmal eine ganz grobe Beschreibung was denn so ein Bean / Component / Repository / .... ist. Das wird jetzt nur eine ganz grobe Sichtweise mit einigen Ungenauigkeiten.

In der Spring Applikation gibt es einige aktive Komponenten, die irgendwas machen.
Typische Beispiele, über die man bei einer Spring Boot Applikation stolpert sind da:

• Repositories - das sind Komponenten, die Daten bereit stellen.
• Controller - Das sind Komponenten, die Anfragen (i.d.R. von außen) annehmen und diese beantworten (z.B. Ein RestController bei einem WebService.)
• Services - Das sind dann Komponenten, die irgend einen Service erbringen.

...

Wenn Du eine Applikation schreibst, dann wäre es normalerweise notwendig, dass Du als Entwickler alles genau schreiben musst: Es soll irgendwas gestartet werden, es soll bei einem Request irgendwas passieren, ....
Und Du musst Dich um Abhängigkeiten kümmern. Dein UserService, der die Benutzer verwaltet braucht ein Repository um auf die Datenbank zu zu greifen. Der Controller, der User Requests bearbeiten soll, braucht den UserService ... Um all das muss man sich kümmern.

Und all das vereinfacht Spring Boot. Da werden zum Beispiel alle Klassen gescannt. Wenn da nun bei einer Klasse gesagt wird, dass da bestimmte Requests behandelt werden soll, dann kümmert sich Spring Boot da z.B. drum. Da muss man also sonst gar nichts machen.
Und auch bei den Abhängigkeiten: Da alle Klassen gescannt werden, kann es sich bestimmte Klassen merken. Alle @Component und co werden z.B. gemerkt. Und es wird analysiert: Denn Spring Boot möchte davon eine Instanz erstellen können. Das kann dann so weit gehen, dass da sogar für ein Interface eine Implementation erstellt wird.

Und das sind dann Dinge, von denen es in der Regel immer nur genau eine Instanz gibt. Das ist also schon ein Merkmal, das Du Dir merken kannst. UserDTO willst Du ja ganz viele haben. Das sieht also erst einmal nicht nach einer Komponente aus.

Was es da als einen zweiten großen Bereich gibt, sind dann die Entities. Die Datenklassen. POJOs. ... Es gibt viele Bezeichnungen. Auch DTO.

Das ist also komplett vom anderen getrennt. (Wir ignorieren einfach einmal komplett die Geschichte - vor 20 Jahren gab es auch EntityBeans und da hat man Entities per JNDI ansprechen/laden können und so ... Je nachdem, was Dir so gefällt, war das halt eine Aktion von Sauron ... oder eine Versuchung von der bösen Seite der Macht. Wurde dann aber durch das Schmieden des Schwertes Hibernate bzw. durch den jungen Jedi Hibernate besiegt. Und das Reich JPA war damit dann gerettet!)

Diese Entities bilden unser Model. Das sind Daten, die transferiert werden können. Das sollte aber vom Namen her schon klar sein. Und da sollte eigentlich User ausreichen - das DTO ist da unnötig. Namen mit DTO habe ich nur, wenn ich einen User habe in meinem Model aber nach außen gebe ich nur einen Teil der Daten. Dann gibt es bei mir ein UserDTO. Und dann gibt es eine Klasse, die für die Umwandlung zuständig ist: User -> UserDTO bzw. UserDTO -> User. Das aber nur etwas am Rande - das ist ein Clean Code Aspekt, den jeder für sich selbst entscheiden sollte.

Ich hoffe, dass diese Sichtweise etwas geholfen hat und ich hoffe, dass ich mit den Ungenauigkeiten / Vereinfachungen in einem Bereich geblieben bin, der nicht zu einem großen Aufschrei führt

Edit: kleine Typos / Verbesserungen