2011-01-07 13 views
3

Ich arbeite an einer großen Java EE 6-Anwendung, die auf JBoss 6 Final bereitgestellt wird. Meine aktuellen Aufgaben beinhalten die konsistente Verwendung von @Inject anstelle von @EJB, aber ich stoße auf einige Arten von Beans, insbesondere auf @MessageDriven Beans und Beans mit @Scheduled-Methoden.Wie funktioniert die CDI-Injektion in MDBs und @Scheduled Beans?

Was passiert, wenn ich mit dem Timing Pech habe (für @Schedule) oder wenn Nachrichten in den Warteschlangen der MDBs beim Start, Instanziierung der Beans scheitern, weil die injizierten Ressourcen (die EJBs selbst sind) sind noch nicht gebunden.

Da ich @Inject verwende, vermute ich, dass der EJB-Container meine Beans als bereit betrachtet, da der Container selbst @Inject nicht interessiert; es wird wahrscheinlich einfach angenommen, dass die Bohnen gebrauchsfertig sind, da es keine @ EJB-Injektionen gibt. Die injizierten CDI-Proxies werden dann fehlschlagen, da die zu injizierenden Ressourcen noch nicht wirklich gebunden sind.

Tiny Beispiel:

@Stateless 
@LocalBean 
public class MySupportingBean { 

    public void doSomething() { 
     ... 
    } 
} 

@Singleton 
public class MyScheduledBean { 

    @Inject 
    private MySupportingBean supportingBean; 

    @Schedule(second = "*/1", hour = "*", minute = "*", persistent = false) 
    public void onTimeout() { 
     supportingBean.doSomething(); 
    } 
} 

Das obige Beispiel wird wahrscheinlich nicht oft scheitern, weil es nur zwei Bohnen sind, aber das Projekt arbeite ich an bindet viele EJBs, die das Problem verstärken wird. Es kann jedoch fehlschlagen, da es keine Garantie gibt, dass MySupportingBean zuerst gebunden wird. Wenn onTimeout vor der Bindung von MySupportBean aufgerufen wird, schlägt die Instanziierung von MyScheduledBean fehl. Wenn ich stattdessen @EJB verwenden würde, wäre MyScheduledBean erst gebunden, wenn die Abhängigkeit von MySupportingBean erfüllt wäre.

Beachten Sie, dass das Beispiel in OnTimeout selbst nicht fehlschlägt, aber wenn CDI versucht, MySupportingBean zu injizieren.

Ich habe viele Beiträge in verschiedenen Foren gelesen, wo viele Leute argumentieren, dass @Inject immer besser ist. Generell stimme ich zu, aber wie behandeln sie @Schedule oder @MessageDriven kombiniert mit @Inject? Meiner Erfahrung nach kommt es darauf an, ob die Beans in diesen Fällen funktionieren oder nicht, und die Beans versagen willkürlich, je nachdem, in welcher Reihenfolge die EJBs eingesetzt werden und wann @Schedule oder onMessage aufgerufen werden.

Antwort

0

Es kann hilfreich sein, die Abhängigkeiten mithilfe der proprietären JBoss-Annotation @Depends explizit zu definieren oder die Datei jboss.xml zu verwenden.

Sehen Sie dies für eine etwas ähnliche Frage: How to order deployment of EJBs and JMS queue config in JBoss 5?

+0

ich diese Möglichkeit in Betracht gezogen, aber Server Agnostiker Anwendung zu sein, ist Art wichtig; Aus politischen Gründen, die weit über mir liegen, werden wir in naher Zukunft wahrscheinlich auf einen anderen App-Server wechseln. Sollten wir uns außerdem auf proprietäre Annotationen verlassen müssen, damit ein generisches Framework wie erwartet funktioniert? –

+1

Sie haben Recht, wir sollten nicht. Aber wenn es hart auf hart kommt, ist manchmal eine praktische Lösung notwendig. Wenn Sie die XML-Datei verwenden, können Sie möglicherweise ähnliche Dateien für alle anderen Hauptserver hinzufügen (haben diese anderen Server sogar dieses Problem?). Ich stimme zu, dass es eine hässliche Lösung ist und hoffe, dass jemand anders eine standardkonforme Antwort geben kann. –

+0

Ich denke du hast Recht. Es ist nicht die Antwort, auf die ich gehofft hatte, aber natürlich müssen wir pragmatisch sein. Von den zwei Übeln denke ich, dass die XML-Datei die kleinere ist - zumindest werde ich keine JBoss-spezifischen Annotationen in den Quellcode einführen. Und wir haben bereits einige Deployment-Deskriptoren für JBoss, die natürlich ohnehin durch einen neuen App-Server ersetzt werden müssen. Wir werden wahrscheinlich in naher Zukunft zu WebSphere wechseln, aber wir haben noch nicht damit begonnen, es zu testen. Es ist interessant zu sehen, ob WebSphere ein ähnliches Verhalten zeigt. –