When you request
@Inject MyDao<Customer> dao;
the container knows that you want a bean specifically of type MyDao<Customer>. If such a bean exists and its type information is known, then the container can satisfy the injection. For example, the type information is preserved in your @Produces annotated method
@Produces
MyDao<Product> getDaoProduct() {
The container uses reflection to retrieve that parameterized type and can match it to the requested @Inject field.
With
abstract class MyView<T> {
@Inject
MyDao<T> dao;
however, all the container knows is that you want a MyDao. T is a type variable, not a concrete parameterization. The container cannot assume a specific type for it. In your case, both of the @Produces beans would match and there would be ambiguity.
In your example, we know from the context that it really wants a MyDao<Customer>. That doesn't seem to be something your container is capable of doing, ie. trying to resolve the type parameter to a concrete type argument for a parameterized subclass.
