Instance, Provider (raw types) and Object.

So now what doe getBeanTypes return?

So we could reword the paragraph like this

The container must provide a built-in bean:

• eligible for all injection point of type Instance<T> and Provider<T>, for any T type and having any set of qualifiers,
• with scope @Dependent,
• with no bean name, and
• an implementation provided automatically by the container.

The built-in implementation must be a passivation capable dependency, as defined in Passivation capable dependencies.

Do you mean that the current behaviour allow me to put a non valid bean type (inject Instance<Foo> where no beans exist with Foo type) ?

Yes. We should not really change the behavior. Even if we were allowed to do so, this is still a valid usecase. You can have a code such as:

@Inject Instance<Foo> instance

if (!instance.isUnsatisfied()) {
    // use foo
    instance.get();
} else {
    // use something other than foo
}

yes rhn-engineering-jharting, that's why I was starting to propose a new way to define the behaviour. Saying that the container doesn't provide all the Instance for all bean type but only check that the Instance you injected is related to a valid bean type. Do you mean that the current behaviour allow me to put a non valid bean type (inject Instance<Foo> where no beans exist with Foo type) ?

No, the behavior is correct. It's the way the behavior is defined that is problematic.

The expected behavior is that no matter what legal type X and qualifiers you choose, you'll always get instance injected for Instance<X> and given qualifiers. The way this is specified is by saying that the built-in bean has

• Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
• every qualifier type in its set of qualifier types

Combined with how CDI resolution rules work this gets the job done (since the built-in bean has all the types and qualifiers, it will always be resolved). In theory this approach is correct. However, it is difficult to materialize since it uses infinite sets (e.g. Bean<Instance>.getTypes() should strictly speaking return and infinite set of all possible bean types) which is inconvenient at best

Ok got it. I read it in the wrong way. So 5.6.2 should become something like:

The container must provide a built-in bean with:

• Instance<?> and Provider<?> in its set of bean types,
• scope @Dependent,
• no bean name, and
• an implementation provided automatically by the container.

For all injection point of type Instance<T> or Provider<T> the container must validate that at least one bean with T in its set of bean types exists. If such a bean doesn't exist, the container automatically detects the problem and treats it as a deployment problem

The built-in implementation must be a passivation capable dependency, as defined in Passivation capable dependencies.

We probably should also mention qualifiers in the validation sentence.

It's not about limitiations. As Jozef pointed out it's hardly possible to implement Instance built-in bean according to requirements. So this is mainly about the correct wording.

mkouba@redhat.comCould give a use case where the current strict rules regarding Instance could bring limitation?

By the way this applies to the built-in Event as well.

The container must provide a built-in bean with:

• Event<X> in its set of bean types, for every Java type X that does not contain a type variable,
• ...

Yes, ok, I see what you mean.

What's intended is that you can resolve a bean of type Instance<any-legal-bean-type>, but I can see that's not exactly what's been written down.

I doubt there is an implementation that would be following this. What can be implied from the spec is that if you obtain the Bean<?> object for the built-in Instance bean and call Bean.getTypes() you should get a huge set of Instance<X> and Provider<X> where X is every possible Java type that matches "2.2.1. Legal bean types".

I think that this would not even be a finite set most of the time so typesafe resolution cannot clearly work this way for the Instance bean.

Martin, why do you think we need to do this?

I think the issue then is you can't look up an Instance for some other bean dynamically...