Absolutely. I just threw that in there right now to get it working quickly as a prototype. That module is still under review so I didn't want to spend time on writing a Java 5 substitute for ServiceLoader until we got it resolved.

Speaking of which, we have brainstormed several approaches to this problem, one of which is to use a custom servlet as a way to capture the BeanManager from an injection and store it in the application context. However, wouldn't it still be reasonable to have an SPI to hide this detail, with the implementation being to consult the application context? JSF's ExternalContext is available through a static call (via FacesContext#getCurrentInstance()), but what about other frameworks like Wicket? You are now faces with the issue of getting access to the application context (maybe there is a way in Wicket).

And one other thought. In the SeamELResolver we want to be able to instantiate the WebBeansELResolver for resolving named beans via EL expressions in the Java API (an example is in a bundle message). But the ELResolver is impl specific. So again, we would need a portable way to instantiate this class. I was going to use an SPI for that and put it in this module. But then we do need an impl per 299 impl.

-Dan