DI performance analysis

[asookazian]

How does Web Beans DI compare to DI in Seam?  I'm not talking about bijection (injection, outjection, disinjection) but strictly injection.  And this does not concern type-safety.

The overhead associated with bijection (and esp. with JSF 1.0 with the getter methods being exec'd multiple times due to the JSF life cycle, for example) in Seam 2.x apps can be very high and the use of @BypassInterceptors is required at times as a performance optimization (i.e. turn off bijection at the class or method level).

Has Web Beans DI been load tested and how is the performance gains/losses compared to Seam?  Will there be improvements in using JSF 2.0 with Web Beans as well?

[gavin.king]

In web beans, there is no outjection (though there are producer fields), and therefore injection happens once at instantiation time.

[asookazian]

So we have reverted from dynamic injection (Seam @In) to static injection like Spring?  Is the performance gains from using static vs. dynamic injection the reason for this reversion?  Dynamic injection is convenient for many use cases (fresh data injection from conversation or session context, for example).

from SiA book:

When you use component configuration, you’re performing static dependency injection.
With static injection, Seam assigns a value to a field or property of a component
instance when it’s created. The value is specified using the EL variant of component
configuration. This style of injection is analogous to that used by other lightweight containers,
such as Spring and the JSF managed bean facility. The assignment happens
once, drawing from resources available at the time the component is instantiated. After
that point, the values of the fields and properties of the component instance aren’t
affected by this mechanism. What’s done is done. The properties get their shot again
when a new instance is created.
Seam also supports a style of dependency injection that’s dynamic. This hook is
activated by placing the @In annotation above a field or JavaBean-style property “setter”
method. Annotation-based injections are resolved each time a method is invoked
on a component.

from the Intro to Web Beans guide:

Web Beans supports three primary mechanisms for dependency injection:
Constructor parameter injection:
public class Checkout {
private final ShoppingCart cart;
@Initializer
public Checkout(ShoppingCart cart) {
this.cart = cart;
}
}
Initializer method parameter injection:
public class Checkout {
private ShoppingCart cart;
@Initializer
void setShoppingCart(ShoppingCart cart) {
this.cart = cart;
}
}
And direct field injection:
public class Checkout {
private @Current ShoppingCart cart;
}
Dependency injection always occurs when the Web Bean instance is first instantiated.

[pmuir]

John Jameson wrote on Jul 08, 2009 22:11:


So we have reverted from dynamic injection (Seam @In) to static injection like Spring?

Read section 5.5 in the PFD.

[luxspes]

Pete Muir wrote on Jul 20, 2009 18:01:

John Jameson wrote on Jul 08, 2009 22:11:


So we have reverted from dynamic injection (Seam @In) to static injection like Spring?

Read section 5.5 in the PFD.

PFD? maybe PDF? Which one? Certainly not webbeans_reference.pdf because Chapter 5 ends at 5.4

[luxspes]

I guess you mean Proposed Final Draft ( contexts-1_0-pfd-spec.pdf ). Yes... 5.5. Dependency injection

[luxspes]

Seems like Contextual instances somewhat deal with this... but I do not fully understand how..

[asookazian]

5.5. Dependency injection
From time to time the container instantiates beans and other Java EE component classes supporting injection. The resulting
instance may or may not be a contextual instance as defined by Section 6.5.2, “Contextual instance of a bean.

The container is required to perform dependency injection whenever it creates one of the following contextual objects:
• contextual instances of session beans, and
• contextual instances of managed beans.
The container is also required to perform dependency injection whenever it instantiates any of the following noncontextual
objects:
• non-contextual instances of session beans (for example, session beans obtained by the application from JNDI or injected
using @EJB),
• non-contextual instances of managed beans, and
• instances of any other Java EE component class supporting injection.

So like GKing stated above, the DI occurs upon bean creation/instantiation only.  This is basically static injection like Spring.

But nobody answered why CDI uses static injection vs. dynamic DI like in Seam...