Problem mit Spring Boot Dependency Injection

Codinho

Neues Mitglied
Hallo liebe Community,
ich möchte derzeit eine Logistikverwaltung mit einem Mail-Client als Referenzprojekt erstellen.
Für das Frontend also die Benutzereingaben habe ich mir überlegt JavaFX zu benutzen, im Hintergrund möchte ich mich den Features von SpringBoot (Dependency Injection) aber vor allem der SpringDataJpa für das Speichern der Daten in einer MySQL Datenbank bedienen.
Nun stoße ich gerade auf ein Problem bezüglich der Dependency Injection.
Bei Folgendem Code (die Klasse MailService ist als @Service annotiert) spuckt mir der Compiler jedoch eine Exception aus die lautet: Cannot invoke "mail.service.MailService.getMails()" because "this.mailService" is null. Habe es auch schon mit einer AppConfig Klasse probiert und darin die Beans der jeweiligen Klassen erstellt, aber leider ohne Erfolg. Stehe gerade ziemlich auf dem Schlauch, da ich es zumindest mit SpringWeb bisher immer so gemacht habe. Liegt es vielleicht an JavaFx?
Java:
@Component
public class Controller {
    
    MailService mailService;
    @FXML ListView<String> listview1;
    @FXML Button newMail;
    @FXML Button refresh;
    @FXML HTMLEditor htmledit;
    
    public Controller() {
        
    }
                
    public Controller(MailService mailService) {
        this.mailService = mailService;
    }
    
    @FXML void listMails() {       
    List<Mail> mails = mailService.getMails();
      for(Mail mail : mails) {
            listview1.getItems().add("Betreff :" +mail.getSubject() + "\n" +
                                     "Absender :" +mail.getSender());
         }
    }
 

Anhänge

  • Screenshot 2025-01-16 220412.png
    Screenshot 2025-01-16 220412.png
    6 KB · Aufrufe: 0
Ich denke das Liegt daran, dass du 2 Konstruktoren hast. Wenn Spring den Default-Ctor verwendet ist MailService natürlich null:
Java:
    MailService mailService;
   
    public Controller() {
       
    }
               
    public Controller(MailService mailService) {
        this.mailService = mailService;
    }

Du solltest solche Felder, welche über einen Ctor initialisiert werden, immer final machen. Dann sagt dir schon der Compiler das hier Mist passiert.
Java:
private final MailService mailService; //-> Compiler: Mist!!!

public Controller() {} //-> hier wird MailService nicht injected!

public Controller(MailService mailService) {
    this.mailService = mailService;
}

PS: Eventuell kann jemand die Beiträge von @bärrr und @freebeer löschen. Das ist ja peinlich! Was sollen denn Leute, die Hilfe suchen, von dem Forum denken? @KonradN
 
Zuletzt bearbeitet:
Ich vermute, es liegt einfach daran, dass er zwei Systeme parallel nutzt, die Instanzen erzeugen.

Er hat einmal Spring Boot. Wenn Spring Boot eine neue Instanz erzeugt, dann wird im Rahmen dessen auch die Injection ausgeführt.
Es kommt aber jetzt noch JavaFX ins Spiel. Er hat ja auch @FXML Annotations, also möchte er wohl, dass der FXMLLoader die entsprechenden Felder auch füllt.

Somit ist nun die Frage: Wie erzeugt er die Instanzen?

Die Lösung könnte sein, dass er sich die Instanz von Spring Boot erzeugen lässt um diese dann an den FXMLLoader zu übergeben. Aber das ist aus meiner Sicht keine saubere Sache. Hier würde ich dazu raten, das deutlich sauberer zu trennen und eben nur auf eine Injection Methode pro Klasse zu vertrauen. Also keine JavaFX Controller die auch zeitgleich eine Spring Boot Component sein sollen!

Im Augenblick bin ich mir unsicher, wie ich das sauber trennen würde. Evtl. den ApplicationContext von SpringApplication.run speichern (und im ersten Schritt über das Singleton Pattern bereit stellen?). Dann hättest Du in dem Controller im Konstruktor Code, der den Context nutzt um die gewünschte Component zu bekommen.

Ansonsten macht es aber natürlich Sinn, da auch das Singleton zu verzichten. So static Dinge vermeide ich gerne. Daher wäre halt der run Aufruf mit Speicherung in der Anwendung und wenn die Anwendung den FXMLLoader nutzt, dann holt es sich den Controller und dann wird direkt der ApplicationContext gesetzt oder man macht ggf. eine Basis Controller Klasse, die dann ein initializeSpringElements(ConfiguraableApplicationContext) hat, die dann aufgerufen wird und die dann die Konkreten Controller überschreiben können....

Ich denke, man müsste das konkrete Konstrukt sehen um dann sinnvolle Refactorings zu machen. Aber das wären so meine ersten Ideen ...
 
PS: Eventuell kann jemand die Beiträge von @bärrr und @freebeer löschen. Das ist ja peinlich! Was sollen denn Leute, die Hilfe suchen, von dem Forum denken? @KonradN

Ich habe eben eine Meinung zu eher veralteten Technologien, und kenne auch keinen, der heute noch seriös FX in Projekten eingesetzt - gerade wenn es um solche Dinge wie Mail Clients, etc. geht. Das ist meine Meinung und die darf ich haben.

ModEdit: Beleidigung entfernt.
 
Zuletzt bearbeitet von einem Moderator:
Und evtl. auch noch mal etwas zu dem "JavaFX ist obsolete"

Da kann man gerne geteilter Meinung sein. Desktop Anwendungen mit Java sind ein sehr kleines Segment. Dadurch gibt es dort viel zu wenig Support. Es fehlen einfach sehr viele AddOns, die bei der UI Entwicklung durchaus Sinn machen.

JavaFX ist aus meiner Sicht mit die modernste UI Library und bis vor paar Monaten wäre das auch meine Empfehlung. Deklarative UIs, Bindings, .... Da gibt es einfach sehr viel, das aus meiner Sicht notwendig ist. Aber Projekte sterbene infach aus - MVVM ist das Pattern meiner Wahl bei UI Anwendungen. Dazu gab/gibt es mvvmFX - nur das Projekt scheint seid ein paar Jahren keine Updates mehr zu bekommen...

Dann bleibt halt nur noch Swing oder SWT. Swing bietet aber extrem wenig aber man kann hier durchaus schauen, was da alles möglich ist und auch schauen, was andere Projekte machen. IntelliJ Community ist Open Source und basiert auf Swing...

SWT ist von eclipse und garantiert nicht schlecht. Bei grossen Projekten kann man sich Eclipse RCP ansehen. Die Eclipse IDE zeigt, was da so mindestens möglich ist. Aber für kleine Client Anwendungen ist es schlicht overkill.

Und hier macht es dann durchaus Sinn, sich einmal anzuschauen, was so alles aktuell der Stand der Dinge ist:
Remote Nutzung als Web Anwendung ist da ein grosses Thema. Incl. dem ganzen drum und dran mit cloud und so.
Und dann kommt man halt auf Lösungen, die oft auf Web Technologien basieren. Das kann dann html/css/js sein, aber es gibt viele Ideen und Lösungen. Javaseitig würde mir vaadin einfallen. Aber auch .NET MAUI und so.

Hier kommen dann auch die entsprechenden AddOns ins Spiel. Funktionale Controls und so. Ich setze auf React und dann z.B. MUI X als component library.
 
Ich vermute, es liegt einfach daran, dass er zwei Systeme parallel nutzt, die Instanzen erzeugen.

Er hat einmal Spring Boot. Wenn Spring Boot eine neue Instanz erzeugt, dann wird im Rahmen dessen auch die Injection ausgeführt.
Es kommt aber jetzt noch JavaFX ins Spiel. Er hat ja auch @FXML Annotations, also möchte er wohl, dass der FXMLLoader die entsprechenden Felder auch füllt.

Somit ist nun die Frage: Wie erzeugt er die Instanzen?

Die Lösung könnte sein, dass er sich die Instanz von Spring Boot erzeugen lässt um diese dann an den FXMLLoader zu übergeben. Aber das ist aus meiner Sicht keine saubere Sache. Hier würde ich dazu raten, das deutlich sauberer zu trennen und eben nur auf eine Injection Methode pro Klasse zu vertrauen. Also keine JavaFX Controller die auch zeitgleich eine Spring Boot Component sein sollen!

Im Augenblick bin ich mir unsicher, wie ich das sauber trennen würde. Evtl. den ApplicationContext von SpringApplication.run speichern (und im ersten Schritt über das Singleton Pattern bereit stellen?). Dann hättest Du in dem Controller im Konstruktor Code, der den Context nutzt um die gewünschte Component zu bekommen.

Ansonsten macht es aber natürlich Sinn, da auch das Singleton zu verzichten. So static Dinge vermeide ich gerne. Daher wäre halt der run Aufruf mit Speicherung in der Anwendung und wenn die Anwendung den FXMLLoader nutzt, dann holt es sich den Controller und dann wird direkt der ApplicationContext gesetzt oder man macht ggf. eine Basis Controller Klasse, die dann ein initializeSpringElements(ConfiguraableApplicationContext) hat, die dann aufgerufen wird und die dann die Konkreten Controller überschreiben können....

Ich denke, man müsste das konkrete Konstrukt sehen um dann sinnvolle Refactorings zu machen. Aber das wären so meine ersten Ideen ...
Es ist natürlich richtig das hier 2 Sachen parallel verwendet werden. Wenn man alles weg lässt, was @FXML-annotiert ist, dann würde die Service- Injection trotzdem nicht funktionieren, wenn 2 Konstruktoren benutzt werden.
 
PS: Eventuell kann jemand die Beiträge von @bärrr und @freebeer löschen. Das ist ja peinlich! Was sollen denn Leute, die Hilfe suchen, von dem Forum denken? @KonradN
freebeer / Codinho sind wohl ein User. Damit ist das der TE, der hier im Thread geantwortet hat.
Bezüglich bärrr wird wohl die Sperre früher oder später kommen.

Es ist natürlich richtig das hier 2 Sachen parallel verwendet werden. Wenn man alles weg lässt, was @FXML-annotiert ist, dann würde die Service- Injection trotzdem nicht funktionieren, wenn 2 Konstruktoren benutzt werden.
Ja, das ist klar. Wobei ich halt nur auf die generelle Problematik aufmerksam machen wollte. Eine Injection kann halt nur funktionieren, wenn die Erzeugung oder Initialisierung vom entsprechenden System vorgenommen wird.
 
Warum sollte man sich denn 2 User anlegen? Um Selbstgespräche zu führen...
Möglicherweise wenn man unter Paranoider Schizophrenie leidet, dann kann für jede Halluzination einen eigenen Account führen.
Also das muss man alles nicht diskutieren. Es gibt einfache Gründe wie Login an einem Rechner nicht bekannt und auf einem anderen hatte man es im Browser gespeichert oder so.... Ich sehe hier aber nichts verwerfliches.

Und wenn irgendwas an MOD Tätigkeit gewünscht wird, dann einfach den Report Knopf nutzen. Dann kann das MOD Team entscheiden ob/wie reagiert wird. Das sollte nicht Bestandteil von Diskussionen werden. Wir haben hier schon genug Abweichung vom eigentlichen, technischen Problem. (Wieso sollte eine einfache Emoji Reaktion gelöscht werden? Das ist ja wirklich einfach nur Ausdruck der eigenen Meinung. Da ist die Frage, ob man bei einem technischen Problem wirklich einfach sagen kann: nutz di Technologie nicht.

Wieso nicht direkt? Der User ist ja bekannt und unerwünscht. Besserung scheint auch nicht in Sicht.
Weil es einfach wenig bringt. Dann macht er sich eben direkt einen neuen Account. Das hatten wir doch alles schon praktiziert...
 

Neue Themen


Zurück
Oben