Hi
Some detailed design question and specification question that is based on
an earlier discussion in the TomEE group.
Assume the following:
- A interface called AnInterface with 3 beans implementing it BeanA, BeanB
and BeanC
- The beans are each annotated by a different @Qualifier, lets call them
@QualifierA, @QualifierB and @QualifierC
Considering the following scenarios/pseudocode does not create a memory
leak (as far as I can see using visualvm) I have the following questions:
a) What of the scenarios are the preferred to use from a performance
perspective (OWB wise)?
b) In scenario 2 and 3 what lifecycle will the @Dependent beans be tied to?
I try to understand b) above and its relation to the §6.4.1 Dependent
Objects of CDI 1.0 specification and specifically the sentence: "An
instance of a bean with scope @Dependent obtained by direct invocation of an
Instance is a dependent object of the instance of Instance."
1)
@RequestScoped
public class FactoryExample1 {
@Inject @Instance<AnInterface> beans;
@Produces @RequestScoped
AnInterface produceBean() {
return beans.select(<qualifier that selects one of the
implementations>);
}
}
2)
@ApplicationScoped
public class FactoryExample1 {
@Produces @RequestScoped
AnInterface produceBean(@Any Instance<AnInterface> beans) {
return beans.select(<qualifier that selects one of the
implementations>);
}
}
3) Same as 2) but with a class with a static producer method
4) Let BeanA, BeanB and BeanC also be @RequestScoped beans
@ApplicationScoped
public class FactoryExample1 {
@Inject @Any @Instance<AnInterface> beans;
@Produces @RequestScoped
AnInterface produceBean() {
return beans.select(<qualifier that selects one of the
implementations>);
}
}
--
Med vänlig hälsning / Best regards
Lars-Fredrik Smedberg
STATEMENT OF CONFIDENTIALITY:
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
address(es) and may contain confidential or privileged information. If
you are not the intended recipient, please notify Lars-Fredrik Smedberg
immediately at [email protected], and destroy all copies of this
message and any attachments.
