SPI (JDK ServiceLoader) vs @EJB injection

[justkeys]

I'm stuck on the mismatch between ServiceLoader (which provides me with all available implementations of some java interface) and @EJB (which provides me of one particular implementation of some @Local annotated interface, which simply fails if multiple are available).

The problem with ServiceLoader is, that it produces instances that are not managed nor injected. The good thing is, that i can add implementations simply by adding jars in my ear file.

The problem with @EJB is that you can not say "give me all implementations, ony by one" like ServiceLocator does; you needto pick one. The good thing is, that the thing is managed, injected, intercepted etc... and that the container calculates the dependency tree and makes sure everything is instantiated in the right order.

I was wondering if anyone had some clever way out of this. How can i have injected all EJB's implementing some @Local interface + influencing the deployment order of these ejb's such that these dependents are instantiated before the service that wants to delegate to them?

[banzeletti]

According to my understanding of the EJB specification it has never been intended to support different implementations for the same interfaces. EJB only requires that there is an implementation, it does not specifiy the behaviour of the container in the case there are more than one implementations. So EJB is probably not the proper means to solve this kind of problem. CDI, however, introduces the notion of "Alternatives", which may come closer to your need (or, if you have the required knowledge at programming time, you may use CDI @Qualifiers as well). As far as I understand, EJB Interfaces were necessary in order to provide the stubs and proxies for remote clients (as far as I guess in order to use something calld "dynamic proxy" or deploy-time code generation). If you want to "look up" available implementations at runtime, EJB simply won't help (as far as I understand).