Warum können @PostConstruct und @Retryable nicht zusammen verwendet werden?

Question

Ich habe eine Feder-Framework-basierte Anwendung mit AnnotationConfigApplicationContext erstellt.

Eine Bean hat eine init-Methode, die eine Verbindung zu einem externen Dienst herstellt. Dies kann mit annotiert werden, um automatisch zu starten, sobald die Bean gestartet ist, was funktioniert.

Um irgendwelche Ausnahmen beim Erstellen dieser Verbindung zu behandeln, möchte ich, dass meine Init-Methode bis zu 5 mal wiederholt, wenn eine Ausnahme abgefangen wird. Wenn ich die Methode mit und @Retryable kommentieren sehe ich die Ausnahme wird einmal geworfen und das Programm beendet - Es scheint @Retryable hat keine Wirkung.

Ich habe @EnableRetry in der Konfigurationsklasse korrekt zusammen mit @Configuration verwendet. Ich habe eine andere Methode B auf der gleichen Bohne erstellt, die als retryable annotiert ist. Wenn diese Methode aufgerufen wird, nachdem die Bean instanziiert wurde, kann ich sehen, dass die Methode wie erwartet wiederholt wird, wenn eine Ausnahme ausgelöst wird.

Meine Gedanken, warum dies nicht funktioniert, ist möglicherweise etwas aspektbezogen oder das Postconstruct passiert bevor das spring-retry Element angehängt wird?

Gibt es tatsächlich eine bessere Möglichkeit, eine Initialisierungsmethode zu verwenden, die Ausnahmen behandeln kann und über Annotationen erneut versucht werden kann - anstatt programmgesteuert in der Methode zu versuchen?

Edit: Ich stimme jetzt zu, dass die Erstellung von Verbindungen zu externen Diensten nicht über @Postconstruct erfolgen soll. Dies kann verhindern, dass der gesamte Kontext initialisiert wird, wenn die Versuche fehlschlagen, was nachteilige Auswirkungen haben kann.

Dies beantwortet jedoch noch nicht die Frage, welcher Teil des Spring Frameworks diese beiden Annotationen nicht in Verbindung bringt.

Answer 1

"@Retryable" ist ein Aspekt, der von "spring-retry" angewendet wird. Dies wird nur angefügt, nachdem der Spring-Kontext vollständig erstellt wurde, dh nachdem alle '@PostConstruct' annotierten Methoden ausgeführt wurden, hat '@Retryable' keine Auswirkung.

Answer 2

Ich würde vorschlagen, dass Sie tatsächlich eine ApplicationListener anwenden, die auf eine ContextRefreshedEvent hört und diese Methode mit Ihrer Wiederholungslogik annotiert hat. Diese Listener werden ausgelöst, sobald der Kontext vollständig aktualisiert und alle Beans ordnungsgemäß konfiguriert und verkabelt wurden.

Answer 3

Um irgendwelche Ausnahmen beim Erstellen dieser Verbindung zu behandeln, möchte ich, dass meine Init-Methode bis zu 5 mal wiederholt, wenn eine Ausnahme abgefangen wird.

Sie sollten NIEMALS mit Ressourcen in Init-Methoden verbinden; Sie sollten darauf warten, dass der Kontext zuerst erstellt wird.

Es ist viel besser zu implementieren SmartLifecycle und verbinden in start(). Auf diese Weise können Sie sicher sein, dass der gesamte Kontext initialisiert wurde, bevor Sie mit der Verbindung zu externen Ressourcen beginnen.

Auf diese Weise sollte die start() Methode von der Wiederholung Interzeptor beraten werden.

Wie @Naros vorgeschlagen hat, ist die ContextRefreshedEvent eine andere Alternative, aber Sie sollten niemals solche Sachen in nie tun.