Three more item that have come up as I've been thinking about this. (1) The proposal above is *much* easier to implement if we have a way to associate something with a context which is not a Web Bean. (The child Manager can't really be modelled as a Web Bean, because all child Managers have the same type/binding types.) So I think we should have a Contextual<T> interface that is implemented by Bean<T>: public interface Contextual<T> { public abstract T create(); public abstract void destroy(T instance); } This would allow infrastructural code to keep contextual information in the Web Beans contexts, without having to jump through hoops to implement the whole contract of Bean. (2) We also need to define exactly when definition/deployment exceptions occur when Beans are added dynamically. I propose that we say that DefinitionExceptions occur when addBean()/addInterceptor()/addDecorator() is invoked, and the DeploymentExceptions occur when the following (new) method of Manager is explicitly invoked: public interface Manager { ... public Manager validate(); } Perhaps we should also explicitly disallow calls to the getInstance(), etc, methods of a child Manager if validate() has not been called. Or we could just say that validate() occurs automagically the first time one of these methods is called. (3) Finally, we need to think carefully about what happens when a Web Bean defined by a child Manager is injectable to a second Web Bean defined by the parent Manager. If the second Web Bean belongs to a scope that is wider than the scope of the child Manager, it may or may not get an instance of the first Web Bean injected, depending upon whether it was instantiated before or after the call to setCurrent()! Even worse, there is the potential for Web Beans defined by the child Manager to "leak" out of the child Manager scope. Scope adaptors are super-helpful here, neatly solving the problem for objects with normal scope. But we might need to say one of the following things - either: * that a Web Bean with scope @Dependent defined for a child Manager may not be bound to injection points of Web Beans defined by the parent Manager, or * that a Web Bean with scope @Dependent defined for a child Manager may not be bound to injection points of Web Beans defined by the parent Manager with scopes other than the scope with which the child Manager is associated (unfortunately, this restriction cannot be enforced by the validate() call, as things are currently defined) Furthermore, we probably need to prohibit a child Manager from defining Web Beans with any scope other than either: * @Dependent * it's own scope to prevent "leakage" of the bean definitions out of the scope of the child Manager. Hmmm, it looks like I need to modify the previous proposal so that the scope of the child Manager is specified when it is created, instead of at the call to setCurrent(). Does all that make sense? On Tue, Nov 18, 2008 at 12:30 PM, Gavin King <gavin(a)hibernate.org&gt; wrote: -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org