You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@openwebbeans.apache.org by Lars-Fredrik Smedberg <it...@gmail.com> on 2015/03/10 01:16:31 UTC
Question on CDI 1.0 spec and impl of @Dependent
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 itsmeden@gmail.com, and destroy all copies of this
message and any attachments.
Re: Question on CDI 1.0 spec and impl of @Dependent
Posted by Lars-Fredrik Smedberg <it...@gmail.com>.
@Mark thanks for the answers... see some follow ups inlined below
Thanks again
LF
On Tue, Mar 10, 2015 at 3:40 PM, Mark Struberg <st...@yahoo.de> wrote:
> Hi!
>
> A deep look at how it works:
>
> 1st: NormalScoped beans get their OWN CreationalContext. @Dependent scoped
> will get stored into their ‚parent‘ CreationalContext.
>
>
>> In example 1 when calling select on the injected Instance<...> of
@Dependent beans I assume that the bean returned by select (if any) will
get stored in their parent CreationalContext, right? In this case I would
get a memory leak if the factory class was @ApplicationScoped (and not
@RequestScoped as the example 1)?
>> If I make the beans implementing AnInterface @RequestScoped I will not
have any problem with an @ApplicationScoped factory class I assume?
>> Can the selected @RequestScoped bean then be returned by the
@RequestScoped producer method? Reason for asking is that I saw some posts
where it was not recommended to both put a scope on the bean and a scope on
the producermethod returning the same bean.
> 2nd: Producer Methods and Producer Fields are OWN Bean<T>. So for your
> sample 2 you have 2 different Bean<T>. a.) the @ApplicationScoped
> FactoryExcample1, b.) the @RequestScoped produceBean method
> (ProducerMethodBean<AnInterface>).
>
> I can only tell you what I >think< will happen in OWB atm :)
For a static producermethod we do _not_ create the ’containing’ instance as
> we do not need it. The Instance<> will get destroyed immediately after the
> method invocation. The created @RequesScoped AnInterface will get stored in
> the given CreationalContext. As this is @RequestScoepd it will be stored in
> the RequestContext and properly be destroyed at the end of the request.
>
>
>> So the "@Any Instance<AnInterface> beans" that is injected in the
non-static producermethod in 2 will be stored the same way as the
@RequestScoped AnInterface, did get that correct?
>> Which of the examples would you say are the most effective performance
wise?
> The problem with having to store the CreationalContext for later
> destruction is ONLY immanent to @Dependent scoped beans.
>
>
>> Do you know if WELD differs in any way from OWB in any of the examples?
> LieGrue,
> strub
>
>
> > Am 10.03.2015 um 01:16 schrieb Lars-Fredrik Smedberg <itsmeden@gmail.com
> >:
> >
> > 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 itsmeden@gmail.com, and destroy all copies of this
> > message and any attachments.
>
>
--
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 itsmeden@gmail.com, and destroy all copies of this
message and any attachments.
Re: Question on CDI 1.0 spec and impl of @Dependent
Posted by Mark Struberg <st...@yahoo.de>.
Hi!
A deep look at how it works:
1st: NormalScoped beans get their OWN CreationalContext. @Dependent scoped will get stored into their ‚parent‘ CreationalContext.
2nd: Producer Methods and Producer Fields are OWN Bean<T>. So for your sample 2 you have 2 different Bean<T>. a.) the @ApplicationScoped FactoryExcample1, b.) the @RequestScoped produceBean method (ProducerMethodBean<AnInterface>).
I can only tell you what I >think< will happen in OWB atm :)
For a static producermethod we do _not_ create the ’containing’ instance as we do not need it. The Instance<> will get destroyed immediately after the method invocation. The created @RequesScoped AnInterface will get stored in the given CreationalContext. As this is @RequestScoepd it will be stored in the RequestContext and properly be destroyed at the end of the request.
The problem with having to store the CreationalContext for later destruction is ONLY immanent to @Dependent scoped beans.
LieGrue,
strub
> Am 10.03.2015 um 01:16 schrieb Lars-Fredrik Smedberg <it...@gmail.com>:
>
> 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 itsmeden@gmail.com, and destroy all copies of this
> message and any attachments.