[webbeans-dev] Re: Redefinition of @New / clarification of injection for non-contextual instances

There's one important thing that is not especially well-defined in the spec today and that has been bothering me for a while. It's to do with injection into non-contextual bean instances. There are a couple of cases where the spec supports injection into non-contextual bean instances: * session beans obtained using JNDI lookup or direct injection using @EJB * @New In each of these cases you get an instance of a bean which is *not* bound to the scope declared by the bean. However, the spec still requires injection into the bean instance. However, there may be multiple "beans" (i.e. instances of Bean) of the given type: * one defined using only annotations * others defined using XML and each "bean" may have different dependencies defined. So the question naturally arises: when I obtain this instance from JNDI or using @New or @EJB, exactly *which* "bean" is it an instance of? i.e. which set of bean metadata should be used? I've not found any completely satisfying answer to this question - but there's only one possibility that is truly well-defined: * it is the one defined using annotations ... even if that bean has a disabled deployment type! I've been thinking about how best to characterize this in the spec, and I think the answer is slightly surprising. We should say that for each bean type, there is one extra "bean", so we now have: * the one defined using only annotations * one that is exactly the same, but with scope @Dependent, binding @New and deployment type @Standard * the others defined using XML We can now characterize session beans obtained using JNDI lookup or @EJB as instances of the bean with binding @New, removing the ambiguity. This approach lets me eliminate section 3.10 (yay!), since there is no longer anything special/magical about @New, and replace it with some shorter notes in 3.2/3.3. Even better, you'll no longer have to use the concrete type of the bean when you inject using @New. This is especially useful for session beans with no bean class local view. So this turns out to be simultaneously a simplification, enhancement and clarification of the spec, and it's also easier to implement! Does that make sense to everybody? Anyway, I guess I will write this up so you guys can see what it looks like in the spec. -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org