2:47 p.m.
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> wrote:
Oracle have a usecase where they want to be able to define Web Beans
within a particular "context" (in their usecase, the context is
something like an orchestration task). I think we can handle this by
providing a hierarchy of Managers. We would add a method to Manager to
create a child, and a method to associate a child (or root) Manager
with the current context associated with a certain active scope:
public interface Manager {
...
public Manager createChild();
public void setCurrent(Class<Annotation> scopeType);
}
A child Manager would inherit all Web Beans, interceptors, decorators,
contexts of its parent, but would allow addition of now ones. So
Oracle's orchestration engine could create a Manager object for each
task definition at startup time, and then when the task started
processing, call setCurrent(TaskScoped.class). When the context ends,
web beans automagically reverts to the root Manager.
What do you guys think?
Bill, do you think this solves the problem you guys have?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org