I looked at the WebBeansContext recently and was a little surprised at what it does and doesn't do. I wonder if what I want it to do is what David Blevins was thinking of as "next steps".
I think of an OWB "instance" set up for a particular application (or web module) as a bunch of instances of implementations of interfaces all wired together. The implementation classes for each interface are (currently) specified in WebBeansConfiguration and in web beans plugins. When a component needs the instance of a particular interface it will get it from the wiring system. My impression is that the information in WebBeansConfiguration and the set of available plugins is intended to be immutable once the OWB "instance" is "started". I believe that before WebBeansContext the lookup to obtain an instance of an interface proceeded through - lookup to obtain WebBeansConfiguration to obtain implementation class - lookup to create or obtain the cached instance of the implementation class. I don't really understand how WebBeansContext changes this significantly. What I would like is for WebBeansContext to supply the complete solution for this behavior so a component can directly get the implementation of an interface from WebBeansContext. I also think we should look into eagerly creating all the components specified in WebBeansConfiguration immediately. I think this will greatly reduce the likelihood of concurrency problems. So I'd like to add these to WebBeansContext: private final Map<Class<?>, Object> serviceMap // service interface class to implementation map public WebBeansContext(WebBeansConfiguration conf) // new constructor to eagerly create all listed services public <T> T getService<Class<T> serviceInterface> // implementation taken from ServiceLoader public <T> void registerService(Class<T> clazz, T t) // in case someone wants to use a non-WebBeansConfiguration configuration scheme. As a more minor point I'm a little confused by the choice of some of the hardcoded services now in WebBeansContext. Some make sense like ConversationManager where there is no interface and no subclasses, but some are specific implementations of service interfaces such as JndiService and ScannerService where IMO the Default* implementations are unlikely to be used in most integration contexts. thoughts? thanks david jencks
