Started working with Weld 1.1.1 and found two issues that probably should be addressed (maybe just documented). They both look to me like leaking implementation details because proxies are used for components which are not @Singleton or @Dependent. @ApplicationScoped public class Bug { public Bug() { System.out.println("########## CONSTRUCT"); } public void foo() { System.out.println("##### FOO"); } public static void main(String[] args) { Weld weld = new Weld(); WeldContainer weldContainer = weld.initialize(); Bug bug = weldContainer.instance().select(Bug.class).get(); // Creates new instance of Bug bug.foo(); // Creates new instance of Bug!!! bug.foo(); // Uses existing instance weld.shutdown(); } } The proxy of Bug will call its superclass constructor several times during the lifecycle of the Bug component. I don't know if that is really necessary, but if it is, you can now no longer use constructors to initialize your component. This is an issue because - it's not documented that constructors of @ApplciationScoped (etc., proxied) components behave differently than @Singleton/@Dependent constructors - even if it's documented, it's questionable if that really should be the case. Taking away constructors as the primary means of initializing a component - e.g. obtaining resources such as database connections, reading config files, etc. - is a major change in the Java programming model. Users have to be strongly advised to use @PostConstruct then.

The other issue I immediately found is also related to behavior of proxies and how transitive initializing/injection is implemented (not sure if this is actually specified somewhere): @ApplicationScoped public class Foo { @Inject Bar bar; } @ApplicationScoped public class Bar { @Inject Baz baz; @PostConstruct void init() { ... } } When I obtain a reference to Foo, I get a proxy of Foo with a reference to a proxy of Bar. The init() method of Bar is never called. The Baz component is never activated. This means I can't transitively initialize an application-scoped graph of components. I was trying to use CDI for wiring in a Swing application and I imagine this would be a common usecase. It should either be documented that there is a difference between @Singleton/@Dependent and proxy-implemented scopes, or unification should be considered.

On May 9, 2011, at 16:49 , Pete Muir wrote: > The init of bar will happen lazily upon first call to a method of Foo. I never loved this behavior but never found a better alternative. I thought that this is probably well known by programmers of Weld/CDI, I've seen the toString() hacks. Not so much by users though.

Started working with Weld 1.1.1 and found two issues that probably should be addressed (maybe just documented). They both look to me like leaking implementation details because proxies are used for components which are not @Singleton or @Dependent. @ApplicationScoped public class Bug { public Bug() { System.out.println("########## CONSTRUCT"); } public void foo() { System.out.println("##### FOO"); } public static void main(String[] args) { Weld weld = new Weld(); WeldContainer weldContainer = weld.initialize(); Bug bug = weldContainer.instance().select(Bug.class).get(); // Creates new instance of Bug bug.foo(); // Creates new instance of Bug!!! bug.foo(); // Uses existing instance weld.shutdown(); } } The proxy of Bug will call its superclass constructor several times during the lifecycle of the Bug component. I don't know if that is really necessary, but if it is, you can now no longer use constructors to initialize your component. This is an issue because - it's not documented that constructors of @ApplciationScoped (etc., proxied) components behave differently than @Singleton/@Dependent constructors - even if it's documented, it's questionable if that really should be the case. Taking away constructors as the primary means of initializing a component - e.g. obtaining resources such as database connections, reading config files, etc. - is a major change in the Java programming model. Users have to be strongly advised to use @PostConstruct then.

actually this behaviour is pretty clear in EE. It's the same thing as we have with EJBs since almost ever. That's why @PostConstruct exists. Whenever object proxies or hidden/transparent serialisation happens, then we need to create the object/proxy on the other side/new invocation. And everytime this happens, the constructer will obviously get called. So this is not a bug and surely not a leak! This was on our list when I did a talk about CDI pitfalls at the JSFdays last year together with Dan. Maybe we should doument this better, but it's nothing for the spec, but the user documentation imo. Also the lazy init is imo a well specified and welcome behaviour. Look at the discussions way back about how to prevent cyclic injection problems. LieGrue, strub --- On Mon, 5/9/11, Christian Bauer <christian.bauer(a)gmail.com&gt; wrote: > From: Christian Bauer <christian.bauer(a)gmail.com&gt; > Subject: [cdi-dev] Proxy implementation leaks > To: cdi-dev(a)lists.jboss.org > Date: Monday, May 9, 2011, 2:46 PM > Started working with Weld 1.1.1 and > found two issues that probably should be addressed (maybe > just documented). They both look to me like leaking > implementation details because proxies are used for > components which are not @Singleton or @Dependent. > > @ApplicationScoped > public class Bug { > > public Bug() { > > System.out.println("########## > CONSTRUCT"); > } > > public void foo() { > System.out.println("##### > FOO"); > } > > public static void main(String[] args) { > Weld weld = new Weld(); > WeldContainer weldContainer > = weld.initialize(); > > Bug bug = > weldContainer.instance().select(Bug.class).get(); // Creates > new instance of Bug > bug.foo(); // Creates new > instance of Bug!!! > bug.foo(); // Uses existing > instance > > weld.shutdown(); > } > } > > The proxy of Bug will call its superclass constructor > several times during the lifecycle of the Bug component. I > don't know if that is really necessary, but if it is, you > can now no longer use constructors to initialize your > component. This is an issue because > > - it's not documented that constructors of > @ApplciationScoped (etc., proxied) components behave > differently than @Singleton/@Dependent constructors > > - even if it's documented, it's questionable if that really > should be the case. > > Taking away constructors as the primary means of > initializing a component - e.g. obtaining resources such as > database connections, reading config files, etc. - is a > major change in the Java programming model. Users have to be > strongly advised to use @PostConstruct then. > > The other issue I immediately found is also related to > behavior of proxies and how transitive > initializing/injection is implemented (not sure if this is > actually specified somewhere): > > @ApplicationScoped > public class Foo { > > @Inject > Bar bar; > > } > > @ApplicationScoped > public class Bar { > > @Inject > Baz baz; > > @PostConstruct > void init() { ... } > > } > > When I obtain a reference to Foo, I get a proxy of Foo with > a reference to a proxy of Bar. The init() method of Bar is > never called. The Baz component is never activated. > > This means I can't transitively initialize an > application-scoped graph of components. I was trying to use > CDI for wiring in a Swing application and I imagine this > would be a common usecase. It should either be documented > that there is a difference between @Singleton/@Dependent and > proxy-implemented scopes, or unification should be > considered. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev >

Hi Pete, how would you instantiate a client proxy, if not via a constructor? You need one call for the proxy and one call for the 'contextual instance'. Or am I missing some available java-magic? Regards, Arne -----Ursprüngliche Nachricht----- Von: cdi-dev-bounces(a)lists.jboss.org [mailto:cdi-dev-bounces@lists.jboss.org] Im Auftrag von Pete Muir Gesendet: Montag, 9. Mai 2011 17:20 An: Mark Struberg Cc: cdi-dev(a)lists.jboss.org Betreff: Re: [cdi-dev] Proxy implementation leaks Thanks Mark, I knew there was a reason for the lazy init. The two-ctor call is not necessary though. On 9 May 2011, at 16:15, Mark Struberg wrote: > actually this behaviour is pretty clear in EE. It's the same thing as we have with EJBs since almost ever. That's why @PostConstruct exists. > > Whenever object proxies or hidden/transparent serialisation happens, then we need to create the object/proxy on the other side/new invocation. And everytime this happens, the constructer will obviously get called. > > So this is not a bug and surely not a leak! > > This was on our list when I did a talk about CDI pitfalls at the JSFdays last year together with Dan. > > Maybe we should doument this better, but it's nothing for the spec, but the user documentation imo. > > Also the lazy init is imo a well specified and welcome behaviour. Look at the discussions way back about how to prevent cyclic injection problems. > > LieGrue, > strub > > --- On Mon, 5/9/11, Christian Bauer <christian.bauer(a)gmail.com&gt; wrote: > >> From: Christian Bauer <christian.bauer(a)gmail.com&gt; >> Subject: [cdi-dev] Proxy implementation leaks >> To: cdi-dev(a)lists.jboss.org >> Date: Monday, May 9, 2011, 2:46 PM >> Started working with Weld 1.1.1 and >> found two issues that probably should be addressed (maybe just >> documented). They both look to me like leaking implementation details >> because proxies are used for components which are not @Singleton or >> @Dependent. >> >> @ApplicationScoped >> public class Bug { >> >> public Bug() { >> >> System.out.println("########## >> CONSTRUCT"); >> } >> >> public void foo() { >> System.out.println("##### >> FOO"); >> } >> >> public static void main(String[] args) { >> Weld weld = new Weld(); >> WeldContainer weldContainer >> = weld.initialize(); >> >> Bug bug = >> weldContainer.instance().select(Bug.class).get(); // Creates new >> instance of Bug >> bug.foo(); // Creates new >> instance of Bug!!! >> bug.foo(); // Uses existing >> instance >> >> weld.shutdown(); >> } >> } >> >> The proxy of Bug will call its superclass constructor several times >> during the lifecycle of the Bug component. I don't know if that is >> really necessary, but if it is, you can now no longer use >> constructors to initialize your component. This is an issue because >> >> - it's not documented that constructors of @ApplciationScoped (etc., >> proxied) components behave differently than @Singleton/@Dependent >> constructors >> >> - even if it's documented, it's questionable if that really should be >> the case. >> >> Taking away constructors as the primary means of initializing a >> component - e.g. obtaining resources such as database connections, >> reading config files, etc. - is a major change in the Java >> programming model. Users have to be strongly advised to use >> @PostConstruct then. >> >> The other issue I immediately found is also related to behavior of >> proxies and how transitive initializing/injection is implemented (not >> sure if this is actually specified somewhere): >> >> @ApplicationScoped >> public class Foo { >> >> @Inject >> Bar bar; >> >> } >> >> @ApplicationScoped >> public class Bar { >> >> @Inject >> Baz baz; >> >> @PostConstruct >> void init() { ... } >> >> } >> >> When I obtain a reference to Foo, I get a proxy of Foo with a >> reference to a proxy of Bar. The init() method of Bar is never >> called. The Baz component is never activated. >> >> This means I can't transitively initialize an application-scoped >> graph of components. I was trying to use CDI for wiring in a Swing >> application and I imagine this would be a common usecase. It should >> either be documented that there is a difference between >> @Singleton/@Dependent and proxy-implemented scopes, or unification >> should be considered. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

was about to ask the same ;) If there is some subclassing involved, then you will need to call the constructor of the superclass. You cannot solve this another way without changing the original class. There is only one magic trick, but this is a pretty heavyweight one: 1.) dynamically create an interface with all the methods from the class hierarchy from the proxied class 2.) create a java.lang.reflect.proxy for the interface 3.) dynamically _change_ the original proxied class to additionally implement the freshly generated interface This is pretty much work, but imo the only way which works. The downsides are that you need to 'enhance' the original class, which might cause ClassCastExceptions and lots of other nasty problems... LieGrue, strub --- On Mon, 5/9/11, Arne Limburg <arne.limburg(a)openknowledge.de&gt; wrote: > From: Arne Limburg <arne.limburg(a)openknowledge.de&gt; > Subject: AW: [cdi-dev] Proxy implementation leaks > To: "Pete Muir" <pmuir(a)redhat.com&gt;, "Mark Struberg" <struberg(a)yahoo.de&gt; > Cc: &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; > Date: Monday, May 9, 2011, 3:26 PM > Hi Pete, > > how would you instantiate a client proxy, if not via a > constructor? You need one call for the proxy and one call > for the 'contextual instance'. > Or am I missing some available java-magic? > > Regards, > Arne > > -----Ursprüngliche Nachricht----- > Von: cdi-dev-bounces(a)lists.jboss.org > [mailto:cdi-dev-bounces@lists.jboss.org] > Im Auftrag von Pete Muir > Gesendet: Montag, 9. Mai 2011 17:20 > An: Mark Struberg > Cc: cdi-dev(a)lists.jboss.org > Betreff: Re: [cdi-dev] Proxy implementation leaks > > Thanks Mark, I knew there was a reason for the lazy init. > > The two-ctor call is not necessary though. > > On 9 May 2011, at 16:15, Mark Struberg wrote: > >> actually this behaviour is pretty clear in EE. It's > the same thing as we have with EJBs since almost ever. > That's why @PostConstruct exists. >> >> Whenever object proxies or hidden/transparent > serialisation happens, then we need to create the > object/proxy on the other side/new invocation. And everytime > this happens, the constructer will obviously get called. >> >> So this is not a bug and surely not a leak! >> >> This was on our list when I did a talk about CDI > pitfalls at the JSFdays last year together with Dan. >> >> Maybe we should doument this better, but it's nothing > for the spec, but the user documentation imo. >> >> Also the lazy init is imo a well specified and welcome > behaviour. Look at the discussions way back about how to > prevent cyclic injection problems. >> >> LieGrue, >> strub >> >> --- On Mon, 5/9/11, Christian Bauer <christian.bauer(a)gmail.com&gt; > wrote: >> >>> From: Christian Bauer <christian.bauer(a)gmail.com&gt; >>> Subject: [cdi-dev] Proxy implementation leaks >>> To: cdi-dev(a)lists.jboss.org >>> Date: Monday, May 9, 2011, 2:46 PM >>> Started working with Weld 1.1.1 and >>> found two issues that probably should be addressed > (maybe just >>> documented). They both look to me like leaking > implementation details >>> because proxies are used for components which are > not @Singleton or >>> @Dependent. >>> >>> @ApplicationScoped >>> public class Bug { >>> >>> public Bug() { >>> >>> System.out.println("########## >>> CONSTRUCT"); >>> } >>> >>> public void foo() { >>> > System.out.println("##### >>> FOO"); >>> } >>> >>> public static void main(String[] > args) { >>> Weld weld = new > Weld(); >>> WeldContainer > weldContainer >>> = weld.initialize(); >>> >>> Bug bug = >>> weldContainer.instance().select(Bug.class).get(); > // Creates new >>> instance of Bug >>> bug.foo(); // Creates > new >>> instance of Bug!!! >>> bug.foo(); // Uses > existing >>> instance >>> >>> weld.shutdown(); >>> } >>> } >>> >>> The proxy of Bug will call its superclass > constructor several times >>> during the lifecycle of the Bug component. I don't > know if that is >>> really necessary, but if it is, you can now no > longer use >>> constructors to initialize your component. This is > an issue because >>> >>> - it's not documented that constructors of > @ApplciationScoped (etc., >>> proxied) components behave differently than > @Singleton/@Dependent >>> constructors >>> >>> - even if it's documented, it's questionable if > that really should be >>> the case. >>> >>> Taking away constructors as the primary means of > initializing a >>> component - e.g. obtaining resources such as > database connections, >>> reading config files, etc. - is a major change in > the Java >>> programming model. Users have to be strongly > advised to use >>> @PostConstruct then. >>> >>> The other issue I immediately found is also > related to behavior of >>> proxies and how transitive initializing/injection > is implemented (not >>> sure if this is actually specified somewhere): >>> >>> @ApplicationScoped >>> public class Foo { >>> >>> @Inject >>> Bar bar; >>> >>> } >>> >>> @ApplicationScoped >>> public class Bar { >>> >>> @Inject >>> Baz baz; >>> >>> @PostConstruct >>> void init() { ... } >>> >>> } >>> >>> When I obtain a reference to Foo, I get a proxy of > Foo with a >>> reference to a proxy of Bar. The init() method of > Bar is never >>> called. The Baz component is never activated. >>> >>> This means I can't transitively initialize an > application-scoped >>> graph of components. I was trying to use CDI for > wiring in a Swing >>> application and I imagine this would be a common > usecase. It should >>> either be documented that there is a difference > between >>> @Singleton/@Dependent and proxy-implemented > scopes, or unification >>> should be considered. >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev >

imo once for *every* instance you create. And each proxy == instance imo. Marius, Stuuu, think we need you guys to clarify this. txs and LieGrue, strub --- On Mon, 5/9/11, Pete Muir <pmuir(a)redhat.com&gt; wrote: > From: Pete Muir <pmuir(a)redhat.com&gt; > Subject: Re: AW: [cdi-dev] Proxy implementation leaks > To: "Mark Struberg" <struberg(a)yahoo.de&gt; > Cc: "Arne Limburg" <arne.limburg(a)openknowledge.de&gt;, &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; > Date: Monday, May 9, 2011, 3:32 PM > You can't enhance the class without > either a javaagent or bytecode instr. > > If you use subclassing you only need to call the ctor of > the superclass once, not twice as it stands today. > > On 9 May 2011, at 16:30, Mark Struberg wrote: > >> was about to ask the same ;) >> >> If there is some subclassing involved, then you will > need to call the constructor of the superclass. You cannot > solve this another way without changing the original class. >> >> There is only one magic trick, but this is a pretty > heavyweight one: >> 1.) dynamically create an interface with all the > methods from the class hierarchy from the proxied class >> 2.) create a java.lang.reflect.proxy for the > interface >> 3.) dynamically _change_ the original proxied class to > additionally implement the freshly generated interface >> >> This is pretty much work, but imo the only way which > works. >> The downsides are that you need to 'enhance' the > original class, which might cause ClassCastExceptions and > lots of other nasty problems... >> >> LieGrue, >> strub >> >> --- On Mon, 5/9/11, Arne Limburg <arne.limburg(a)openknowledge.de&gt; > wrote: >> >>> From: Arne Limburg <arne.limburg(a)openknowledge.de&gt; >>> Subject: AW: [cdi-dev] Proxy implementation leaks >>> To: "Pete Muir" <pmuir(a)redhat.com&gt;, > "Mark Struberg" <struberg(a)yahoo.de&gt; >>> Cc: &quot;cdi-dev(a)lists.jboss.org&quot; > <cdi-dev(a)lists.jboss.org&gt; >>> Date: Monday, May 9, 2011, 3:26 PM >>> Hi Pete, >>> >>> how would you instantiate a client proxy, if not > via a >>> constructor? You need one call for the proxy and > one call >>> for the 'contextual instance'. >>> Or am I missing some available java-magic? >>> >>> Regards, >>> Arne >>> >>> -----Ursprüngliche Nachricht----- >>> Von: cdi-dev-bounces(a)lists.jboss.org >>> [mailto:cdi-dev-bounces@lists.jboss.org] >>> Im Auftrag von Pete Muir >>> Gesendet: Montag, 9. Mai 2011 17:20 >>> An: Mark Struberg >>> Cc: cdi-dev(a)lists.jboss.org >>> Betreff: Re: [cdi-dev] Proxy implementation leaks >>> >>> Thanks Mark, I knew there was a reason for the > lazy init. >>> >>> The two-ctor call is not necessary though. >>> >>> On 9 May 2011, at 16:15, Mark Struberg wrote: >>> >>>> actually this behaviour is pretty clear in EE. > It's >>> the same thing as we have with EJBs since almost > ever. >>> That's why @PostConstruct exists. >>>> >>>> Whenever object proxies or hidden/transparent >>> serialisation happens, then we need to create the >>> object/proxy on the other side/new invocation. And > everytime >>> this happens, the constructer will obviously get > called. >>>> >>>> So this is not a bug and surely not a leak! >>>> >>>> This was on our list when I did a talk about > CDI >>> pitfalls at the JSFdays last year together with > Dan. >>>> >>>> Maybe we should doument this better, but it's > nothing >>> for the spec, but the user documentation imo. >>>> >>>> Also the lazy init is imo a well specified and > welcome >>> behaviour. Look at the discussions way back about > how to >>> prevent cyclic injection problems. >>>> >>>> LieGrue, >>>> strub >>>> >>>> --- On Mon, 5/9/11, Christian Bauer <christian.bauer(a)gmail.com&gt; >>> wrote: >>>> >>>>> From: Christian Bauer <christian.bauer(a)gmail.com&gt; >>>>> Subject: [cdi-dev] Proxy implementation > leaks >>>>> To: cdi-dev(a)lists.jboss.org >>>>> Date: Monday, May 9, 2011, 2:46 PM >>>>> Started working with Weld 1.1.1 and >>>>> found two issues that probably should be > addressed >>> (maybe just >>>>> documented). They both look to me like > leaking >>> implementation details >>>>> because proxies are used for components > which are >>> not @Singleton or >>>>> @Dependent. >>>>> >>>>> @ApplicationScoped >>>>> public class Bug { >>>>> >>>>> public Bug() { >>>>> >>>>> > System.out.println("########## >>>>> CONSTRUCT"); >>>>> } >>>>> >>>>> public void foo() > { >>>>> >>> System.out.println("##### >>>>> FOO"); >>>>> } >>>>> >>>>> public static void > main(String[] >>> args) { >>>>> Weld > weld = new >>> Weld(); >>>>> > WeldContainer >>> weldContainer >>>>> = weld.initialize(); >>>>> >>>>> Bug > bug = >>>>> > weldContainer.instance().select(Bug.class).get(); >>> // Creates new >>>>> instance of Bug >>>>> > bug.foo(); // Creates >>> new >>>>> instance of Bug!!! >>>>> > bug.foo(); // Uses >>> existing >>>>> instance >>>>> >>>>> > weld.shutdown(); >>>>> } >>>>> } >>>>> >>>>> The proxy of Bug will call its superclass >>> constructor several times >>>>> during the lifecycle of the Bug component. > I don't >>> know if that is >>>>> really necessary, but if it is, you can > now no >>> longer use >>>>> constructors to initialize your component. > This is >>> an issue because >>>>> >>>>> - it's not documented that constructors > of >>> @ApplciationScoped (etc., >>>>> proxied) components behave differently > than >>> @Singleton/@Dependent >>>>> constructors >>>>> >>>>> - even if it's documented, it's > questionable if >>> that really should be >>>>> the case. >>>>> >>>>> Taking away constructors as the primary > means of >>> initializing a >>>>> component - e.g. obtaining resources such > as >>> database connections, >>>>> reading config files, etc. - is a major > change in >>> the Java >>>>> programming model. Users have to be > strongly >>> advised to use >>>>> @PostConstruct then. >>>>> >>>>> The other issue I immediately found is > also >>> related to behavior of >>>>> proxies and how transitive > initializing/injection >>> is implemented (not >>>>> sure if this is actually specified > somewhere): >>>>> >>>>> @ApplicationScoped >>>>> public class Foo { >>>>> >>>>> @Inject >>>>> Bar bar; >>>>> >>>>> } >>>>> >>>>> @ApplicationScoped >>>>> public class Bar { >>>>> >>>>> @Inject >>>>> Baz baz; >>>>> >>>>> @PostConstruct >>>>> void init() { ... } >>>>> >>>>> } >>>>> >>>>> When I obtain a reference to Foo, I get a > proxy of >>> Foo with a >>>>> reference to a proxy of Bar. The init() > method of >>> Bar is never >>>>> called. The Baz component is never > activated. >>>>> >>>>> This means I can't transitively initialize > an >>> application-scoped >>>>> graph of components. I was trying to use > CDI for >>> wiring in a Swing >>>>> application and I imagine this would be a > common >>> usecase. It should >>>>> either be documented that there is a > difference >>> between >>>>> @Singleton/@Dependent and > proxy-implemented >>> scopes, or unification >>>>> should be considered. >>>>> >>>>> >>>>> > _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> > >

Thanks Mark, I knew there was a reason for the lazy init. The two-ctor call is not necessary though. On 9 May 2011, at 16:15, Mark Struberg wrote: > actually this behaviour is pretty clear in EE. It's the same thing as we have with EJBs since almost ever. That's why @PostConstruct exists. > > Whenever object proxies or hidden/transparent serialisation happens, then we need to create the object/proxy on the other side/new invocation. And everytime this happens, the constructer will obviously get called. > > So this is not a bug and surely not a leak! > > This was on our list when I did a talk about CDI pitfalls at the JSFdays last year together with Dan. > > Maybe we should doument this better, but it's nothing for the spec, but the user documentation imo. > > Also the lazy init is imo a well specified and welcome behaviour. Look at the discussions way back about how to prevent cyclic injection problems. > > LieGrue, > strub > > --- On Mon, 5/9/11, Christian Bauer <christian.bauer(a)gmail.com&gt; wrote: > >> From: Christian Bauer <christian.bauer(a)gmail.com&gt; >> Subject: [cdi-dev] Proxy implementation leaks >> To: cdi-dev(a)lists.jboss.org >> Date: Monday, May 9, 2011, 2:46 PM >> Started working with Weld 1.1.1 and >> found two issues that probably should be addressed (maybe >> just documented). They both look to me like leaking >> implementation details because proxies are used for >> components which are not @Singleton or @Dependent. >> >> @ApplicationScoped >> public class Bug { >> >> public Bug() { >> >> System.out.println("########## >> CONSTRUCT"); >> } >> >> public void foo() { >> System.out.println("##### >> FOO"); >> } >> >> public static void main(String[] args) { >> Weld weld = new Weld(); >> WeldContainer weldContainer >> = weld.initialize(); >> >> Bug bug = >> weldContainer.instance().select(Bug.class).get(); // Creates >> new instance of Bug >> bug.foo(); // Creates new >> instance of Bug!!! >> bug.foo(); // Uses existing >> instance >> >> weld.shutdown(); >> } >> } >> >> The proxy of Bug will call its superclass constructor >> several times during the lifecycle of the Bug component. I >> don't know if that is really necessary, but if it is, you >> can now no longer use constructors to initialize your >> component. This is an issue because >> >> - it's not documented that constructors of >> @ApplciationScoped (etc., proxied) components behave >> differently than @Singleton/@Dependent constructors >> >> - even if it's documented, it's questionable if that really >> should be the case. >> >> Taking away constructors as the primary means of >> initializing a component - e.g. obtaining resources such as >> database connections, reading config files, etc. - is a >> major change in the Java programming model. Users have to be >> strongly advised to use @PostConstruct then. >> >> The other issue I immediately found is also related to >> behavior of proxies and how transitive >> initializing/injection is implemented (not sure if this is >> actually specified somewhere): >> >> @ApplicationScoped >> public class Foo { >> >> @Inject >> Bar bar; >> >> } >> >> @ApplicationScoped >> public class Bar { >> >> @Inject >> Baz baz; >> >> @PostConstruct >> void init() { ... } >> >> } >> >> When I obtain a reference to Foo, I get a proxy of Foo with >> a reference to a proxy of Bar. The init() method of Bar is >> never called. The Baz component is never activated. >> >> This means I can't transitively initialize an >> application-scoped graph of components. I was trying to use >> CDI for wiring in a Swing application and I imagine this >> would be a common usecase. It should either be documented >> that there is a difference between @Singleton/@Dependent and >> proxy-implemented scopes, or unification should be >> considered. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

Doing this in 2 phases is exactly what I mean with lazy initialisation. For the cyclic injection prevention it doesn't matter _how_ lazy. As you said: without splitting the proxy creation from the contextual instance creation, we would not be able to do proper cyclic injection. For this to work this must be a 2 staged process. Like with forward references in compilers.

Of course the current _very_ lazy behaviour might lead to curious situations sometimes (as in my example). But the 'eager' mechanism might lead to 'Context not active' Exceptions if you e.g. have a @RequestScoped field which isn't even touched when an @ApllicationScoped reference gets created in an asynchronous EJB. So you can decide between bad and evil ;)

LieGrue, strub --- On Tue, 5/24/11, Pete Muir <pmuir(a)redhat.com&gt; wrote: > From: Pete Muir <pmuir(a)redhat.com&gt; > Subject: Re: [cdi-dev] Proxy implementation leaks > To: "Pete Muir" <pmuir(a)redhat.com&gt; > Cc: "Mark Struberg" <struberg(a)yahoo.de&gt;, cdi-dev(a)lists.jboss.org > Date: Tuesday, May 24, 2011, 5:47 PM > On reflection, I don't believe this > is correct. The lazy init doesn't help with cyclic > injection, it is simply the presence of proxies that does > this. > > Consider that the DI graph is created using proxies, and > call this phase 1. Weld currently does phase 1 on > injection. > > Phase 2 is the actual instantiation of the objects backing > this graph. Weld currently does phase 2 lazily, when the > first method on a proxy is called and needs to be passed to > the bean (and this repeats through the graph). > > We need to split this into two phases, but there is no > reason that we can't require implementations to do phase 2 > immediately that phase 1 has completed, before we give > control to client code. > > On 9 May 2011, at 16:19, Pete Muir wrote: > >> Thanks Mark, I knew there was a reason for the lazy > init. >> >> The two-ctor call is not necessary though. >> >> On 9 May 2011, at 16:15, Mark Struberg wrote: >> >>> actually this behaviour is pretty clear in EE. > It's the same thing as we have with EJBs since almost ever. > That's why @PostConstruct exists. >>> >>> Whenever object proxies or hidden/transparent > serialisation happens, then we need to create the > object/proxy on the other side/new invocation. And everytime > this happens, the constructer will obviously get called. >>> >>> So this is not a bug and surely not a leak! >>> >>> This was on our list when I did a talk about CDI > pitfalls at the JSFdays last year together with Dan. >>> >>> Maybe we should doument this better, but it's > nothing for the spec, but the user documentation imo. >>> >>> Also the lazy init is imo a well specified and > welcome behaviour. Look at the discussions way back about > how to prevent cyclic injection problems. >>> >>> LieGrue, >>> strub >>> >>> --- On Mon, 5/9/11, Christian Bauer <christian.bauer(a)gmail.com&gt; > wrote: >>> >>>> From: Christian Bauer <christian.bauer(a)gmail.com&gt; >>>> Subject: [cdi-dev] Proxy implementation leaks >>>> To: cdi-dev(a)lists.jboss.org >>>> Date: Monday, May 9, 2011, 2:46 PM >>>> Started working with Weld 1.1.1 and >>>> found two issues that probably should be > addressed (maybe >>>> just documented). They both look to me like > leaking >>>> implementation details because proxies are > used for >>>> components which are not @Singleton or > @Dependent. >>>> >>>> @ApplicationScoped >>>> public class Bug { >>>> >>>> public Bug() { >>>> >>>> System.out.println("########## >>>> CONSTRUCT"); >>>> } >>>> >>>> public void foo() { >>>> > System.out.println("##### >>>> FOO"); >>>> } >>>> >>>> public static void > main(String[] args) { >>>> Weld weld = new > Weld(); >>>> WeldContainer > weldContainer >>>> = weld.initialize(); >>>> >>>> Bug bug = >>>> > weldContainer.instance().select(Bug.class).get(); // > Creates >>>> new instance of Bug >>>> bug.foo(); // > Creates new >>>> instance of Bug!!! >>>> bug.foo(); // > Uses existing >>>> instance >>>> >>>> > weld.shutdown(); >>>> } >>>> } >>>> >>>> The proxy of Bug will call its superclass > constructor >>>> several times during the lifecycle of the Bug > component. I >>>> don't know if that is really necessary, but if > it is, you >>>> can now no longer use constructors to > initialize your >>>> component. This is an issue because >>>> >>>> - it's not documented that constructors of >>>> @ApplciationScoped (etc., proxied) components > behave >>>> differently than @Singleton/@Dependent > constructors >>>> >>>> - even if it's documented, it's questionable > if that really >>>> should be the case. >>>> >>>> Taking away constructors as the primary means > of >>>> initializing a component - e.g. obtaining > resources such as >>>> database connections, reading config files, > etc. - is a >>>> major change in the Java programming model. > Users have to be >>>> strongly advised to use @PostConstruct then. >>>> >>>> The other issue I immediately found is also > related to >>>> behavior of proxies and how transitive >>>> initializing/injection is implemented (not > sure if this is >>>> actually specified somewhere): >>>> >>>> @ApplicationScoped >>>> public class Foo { >>>> >>>> @Inject >>>> Bar bar; >>>> >>>> } >>>> >>>> @ApplicationScoped >>>> public class Bar { >>>> >>>> @Inject >>>> Baz baz; >>>> >>>> @PostConstruct >>>> void init() { ... } >>>> >>>> } >>>> >>>> When I obtain a reference to Foo, I get a > proxy of Foo with >>>> a reference to a proxy of Bar. The init() > method of Bar is >>>> never called. The Baz component is never > activated. >>>> >>>> This means I can't transitively initialize an >>>> application-scoped graph of components. I was > trying to use >>>> CDI for wiring in a Swing application and I > imagine this >>>> would be a common usecase. It should either be > documented >>>> that there is a difference between > @Singleton/@Dependent and >>>> proxy-implemented scopes, or unification > should be >>>> considered. >>>>

> Don't quite get this, spec requires that contexts are > active only at particular points. yes but imagine the following @ApplicationScoped public class MyService { private @Inject User usr; /* User is RequestScoped */ ... } and this MyService will first get invoked in an EJB which gets initialized at startup. At this time there is NO Request Context active! Thus if you would require all contextual instances being created immediately, then you would get a ContextNotActiveException...

LieGrue, strub --- On Tue, 5/24/11, Pete Muir <pmuir(a)redhat.com&gt; wrote: > From: Pete Muir <pmuir(a)redhat.com&gt; > Subject: Re: [cdi-dev] Proxy implementation leaks > To: "Mark Struberg" <struberg(a)yahoo.de&gt; > Cc: cdi-dev(a)lists.jboss.org > Date: Tuesday, May 24, 2011, 7:10 PM > > On 24 May 2011, at 19:38, Mark Struberg wrote: > >> Doing this in 2 phases is exactly what I mean with > lazy initialisation. For the cyclic injection prevention it > doesn't matter _how_ lazy. >> >> As you said: without splitting the proxy creation from > the contextual instance creation, we would not be able to do > proper cyclic injection. For this to work this must be a 2 > staged process. Like with forward references in compilers. > > Yes, however we can require that this is all done by a > certain point. > >> Of course the current _very_ lazy behaviour might lead > to curious situations sometimes (as in my example). But the > 'eager' mechanism might lead to 'Context not active' > Exceptions if you e.g. have a @RequestScoped field which > isn't even touched when an @ApllicationScoped reference gets > created in an asynchronous EJB. So you can decide between > bad and evil ;) > > Don't quite get this, spec requires that contexts are > active only at particular points. > >> >> LieGrue, >> strub >> >> --- On Tue, 5/24/11, Pete Muir <pmuir(a)redhat.com&gt; > wrote: >> >>> From: Pete Muir <pmuir(a)redhat.com&gt; >>> Subject: Re: [cdi-dev] Proxy implementation leaks >>> To: "Pete Muir" <pmuir(a)redhat.com&gt; >>> Cc: "Mark Struberg" <struberg(a)yahoo.de&gt;, > cdi-dev(a)lists.jboss.org >>> Date: Tuesday, May 24, 2011, 5:47 PM >>> On reflection, I don't believe this >>> is correct. The lazy init doesn't help with > cyclic >>> injection, it is simply the presence of proxies > that does >>> this. >>> >>> Consider that the DI graph is created using > proxies, and >>> call this phase 1. Weld currently does phase 1 on >>> injection. >>> >>> Phase 2 is the actual instantiation of the objects > backing >>> this graph. Weld currently does phase 2 lazily, > when the >>> first method on a proxy is called and needs to be > passed to >>> the bean (and this repeats through the graph). >>> >>> We need to split this into two phases, but there > is no >>> reason that we can't require implementations to do > phase 2 >>> immediately that phase 1 has completed, before we > give >>> control to client code. >>> >>> On 9 May 2011, at 16:19, Pete Muir wrote: >>> >>>> Thanks Mark, I knew there was a reason for the > lazy >>> init. >>>> >>>> The two-ctor call is not necessary though. >>>> >>>> On 9 May 2011, at 16:15, Mark Struberg wrote: >>>> >>>>> actually this behaviour is pretty clear in > EE. >>> It's the same thing as we have with EJBs since > almost ever. >>> That's why @PostConstruct exists. >>>>> >>>>> Whenever object proxies or > hidden/transparent >>> serialisation happens, then we need to create the >>> object/proxy on the other side/new invocation. And > everytime >>> this happens, the constructer will obviously get > called. >>>>> >>>>> So this is not a bug and surely not a > leak! >>>>> >>>>> This was on our list when I did a talk > about CDI >>> pitfalls at the JSFdays last year together with > Dan. >>>>> >>>>> Maybe we should doument this better, but > it's >>> nothing for the spec, but the user documentation > imo. >>>>> >>>>> Also the lazy init is imo a well specified > and >>> welcome behaviour. Look at the discussions way > back about >>> how to prevent cyclic injection problems. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> --- On Mon, 5/9/11, Christian Bauer <christian.bauer(a)gmail.com&gt; >>> wrote: >>>>> >>>>>> From: Christian Bauer <christian.bauer(a)gmail.com&gt; >>>>>> Subject: [cdi-dev] Proxy > implementation leaks >>>>>> To: cdi-dev(a)lists.jboss.org >>>>>> Date: Monday, May 9, 2011, 2:46 PM >>>>>> Started working with Weld 1.1.1 and >>>>>> found two issues that probably should > be >>> addressed (maybe >>>>>> just documented). They both look to me > like >>> leaking >>>>>> implementation details because proxies > are >>> used for >>>>>> components which are not @Singleton > or >>> @Dependent. >>>>>> >>>>>> @ApplicationScoped >>>>>> public class Bug { >>>>>> >>>>>> public Bug() { >>>>>> >>>>>> > System.out.println("########## >>>>>> CONSTRUCT"); >>>>>> } >>>>>> >>>>>> public void foo() { >>>>>> >>> System.out.println("##### >>>>>> FOO"); >>>>>> } >>>>>> >>>>>> public static void >>> main(String[] args) { >>>>>> Weld weld = > new >>> Weld(); >>>>>> > WeldContainer >>> weldContainer >>>>>> = weld.initialize(); >>>>>> >>>>>> Bug bug = >>>>>> >>> weldContainer.instance().select(Bug.class).get(); > // >>> Creates >>>>>> new instance of Bug >>>>>> bug.foo(); > // >>> Creates new >>>>>> instance of Bug!!! >>>>>> bug.foo(); > // >>> Uses existing >>>>>> instance >>>>>> >>>>>> >>> weld.shutdown(); >>>>>> } >>>>>> } >>>>>> >>>>>> The proxy of Bug will call its > superclass >>> constructor >>>>>> several times during the lifecycle of > the Bug >>> component. I >>>>>> don't know if that is really > necessary, but if >>> it is, you >>>>>> can now no longer use constructors to >>> initialize your >>>>>> component. This is an issue because >>>>>> >>>>>> - it's not documented that > constructors of >>>>>> @ApplciationScoped (etc., proxied) > components >>> behave >>>>>> differently than > @Singleton/@Dependent >>> constructors >>>>>> >>>>>> - even if it's documented, it's > questionable >>> if that really >>>>>> should be the case. >>>>>> >>>>>> Taking away constructors as the > primary means >>> of >>>>>> initializing a component - e.g. > obtaining >>> resources such as >>>>>> database connections, reading config > files, >>> etc. - is a >>>>>> major change in the Java programming > model. >>> Users have to be >>>>>> strongly advised to use @PostConstruct > then. >>>>>> >>>>>> The other issue I immediately found is > also >>> related to >>>>>> behavior of proxies and how > transitive >>>>>> initializing/injection is implemented > (not >>> sure if this is >>>>>> actually specified somewhere): >>>>>> >>>>>> @ApplicationScoped >>>>>> public class Foo { >>>>>> >>>>>> @Inject >>>>>> Bar bar; >>>>>> >>>>>> } >>>>>> >>>>>> @ApplicationScoped >>>>>> public class Bar { >>>>>> >>>>>> @Inject >>>>>> Baz baz; >>>>>> >>>>>> > @PostConstruct >>>>>> void init() { > ... } >>>>>> >>>>>> } >>>>>> >>>>>> When I obtain a reference to Foo, I > get a >>> proxy of Foo with >>>>>> a reference to a proxy of Bar. The > init() >>> method of Bar is >>>>>> never called. The Baz component is > never >>> activated. >>>>>> >>>>>> This means I can't transitively > initialize an >>>>>> application-scoped graph of > components. I was >>> trying to use >>>>>> CDI for wiring in a Swing application > and I >>> imagine this >>>>>> would be a common usecase. It should > either be >>> documented >>>>>> that there is a difference between >>> @Singleton/@Dependent and >>>>>> proxy-implemented scopes, or > unification >>> should be >>>>>> considered. >>>>>> > >

Imo it is surprising, since it would break all kinds of 'business injections' (as opposed to classic 'resource injections' - Jens Schumann can explain this well ;)

I think 5.4.2. Client proxy invocation + 6.5.2. Contextual instance of a bean goes rather in the direction of _very_ lazy initialization ;)

Imho, the current behaviour of Weld, OWB and CanDI is correct. LieGrue, strub --- On Tue, 5/24/11, Pete Muir <pmuir(a)redhat.com&gt; wrote: > From: Pete Muir <pmuir(a)redhat.com&gt; > Subject: Re: [cdi-dev] Proxy implementation leaks > To: "Mark Struberg" <struberg(a)yahoo.de&gt; > Cc: cdi-dev(a)lists.jboss.org > Date: Tuesday, May 24, 2011, 7:24 PM > > On 24 May 2011, at 20:15, Mark Struberg wrote: > >>> Don't quite get this, spec requires that contexts > are >>> active only at particular points. >> >> yes but imagine the following >> >> @ApplicationScoped >> public class MyService { >> private @Inject User usr; /* User is RequestScoped */ >> >> ... >> } >> >> and this MyService will first get invoked in an EJB > which gets initialized at startup. At this time there is NO > Request Context active! >> Thus if you would require all contextual instances > being created immediately, then you would get a > ContextNotActiveException... > > Yes, but this isn't that surprising and the principle of > least surprise is a good one to follow ;-) > >> >> LieGrue, >> strub >> >> --- On Tue, 5/24/11, Pete Muir <pmuir(a)redhat.com&gt; > wrote: >> >>> From: Pete Muir <pmuir(a)redhat.com&gt; >>> Subject: Re: [cdi-dev] Proxy implementation leaks >>> To: "Mark Struberg" <struberg(a)yahoo.de&gt; >>> Cc: cdi-dev(a)lists.jboss.org >>> Date: Tuesday, May 24, 2011, 7:10 PM >>> >>> On 24 May 2011, at 19:38, Mark Struberg wrote: >>> >>>> Doing this in 2 phases is exactly what I mean > with >>> lazy initialisation. For the cyclic injection > prevention it >>> doesn't matter _how_ lazy. >>>> >>>> As you said: without splitting the proxy > creation from >>> the contextual instance creation, we would not be > able to do >>> proper cyclic injection. For this to work this > must be a 2 >>> staged process. Like with forward references in > compilers. >>> >>> Yes, however we can require that this is all done > by a >>> certain point. >>> >>>> Of course the current _very_ lazy behaviour > might lead >>> to curious situations sometimes (as in my > example). But the >>> 'eager' mechanism might lead to 'Context not > active' >>> Exceptions if you e.g. have a @RequestScoped field > which >>> isn't even touched when an @ApllicationScoped > reference gets >>> created in an asynchronous EJB. So you can decide > between >>> bad and evil ;) >>> >>> Don't quite get this, spec requires that contexts > are >>> active only at particular points. >>> >>>> >>>> LieGrue, >>>> strub >>>> >>>> --- On Tue, 5/24/11, Pete Muir <pmuir(a)redhat.com&gt; >>> wrote: >>>> >>>>> From: Pete Muir <pmuir(a)redhat.com&gt; >>>>> Subject: Re: [cdi-dev] Proxy > implementation leaks >>>>> To: "Pete Muir" <pmuir(a)redhat.com&gt; >>>>> Cc: "Mark Struberg" <struberg(a)yahoo.de&gt;, >>> cdi-dev(a)lists.jboss.org >>>>> Date: Tuesday, May 24, 2011, 5:47 PM >>>>> On reflection, I don't believe this >>>>> is correct. The lazy init doesn't help > with >>> cyclic >>>>> injection, it is simply the presence of > proxies >>> that does >>>>> this. >>>>> >>>>> Consider that the DI graph is created > using >>> proxies, and >>>>> call this phase 1. Weld currently does > phase 1 on >>>>> injection. >>>>> >>>>> Phase 2 is the actual instantiation of the > objects >>> backing >>>>> this graph. Weld currently does phase 2 > lazily, >>> when the >>>>> first method on a proxy is called and > needs to be >>> passed to >>>>> the bean (and this repeats through the > graph). >>>>> >>>>> We need to split this into two phases, but > there >>> is no >>>>> reason that we can't require > implementations to do >>> phase 2 >>>>> immediately that phase 1 has completed, > before we >>> give >>>>> control to client code. >>>>> >>>>> On 9 May 2011, at 16:19, Pete Muir wrote: >>>>> >>>>>> Thanks Mark, I knew there was a reason > for the >>> lazy >>>>> init. >>>>>> >>>>>> The two-ctor call is not necessary > though. >>>>>> >>>>>> On 9 May 2011, at 16:15, Mark Struberg > wrote: >>>>>> >>>>>>> actually this behaviour is pretty > clear in >>> EE. >>>>> It's the same thing as we have with EJBs > since >>> almost ever. >>>>> That's why @PostConstruct exists. >>>>>>> >>>>>>> Whenever object proxies or >>> hidden/transparent >>>>> serialisation happens, then we need to > create the >>>>> object/proxy on the other side/new > invocation. And >>> everytime >>>>> this happens, the constructer will > obviously get >>> called. >>>>>>> >>>>>>> So this is not a bug and surely > not a >>> leak! >>>>>>> >>>>>>> This was on our list when I did a > talk >>> about CDI >>>>> pitfalls at the JSFdays last year together > with >>> Dan. >>>>>>> >>>>>>> Maybe we should doument this > better, but >>> it's >>>>> nothing for the spec, but the user > documentation >>> imo. >>>>>>> >>>>>>> Also the lazy init is imo a well > specified >>> and >>>>> welcome behaviour. Look at the discussions > way >>> back about >>>>> how to prevent cyclic injection problems. >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> --- On Mon, 5/9/11, Christian > Bauer <christian.bauer(a)gmail.com&gt; >>>>> wrote: >>>>>>> >>>>>>>> From: Christian Bauer <christian.bauer(a)gmail.com&gt; >>>>>>>> Subject: [cdi-dev] Proxy >>> implementation leaks >>>>>>>> To: cdi-dev(a)lists.jboss.org >>>>>>>> Date: Monday, May 9, 2011, > 2:46 PM >>>>>>>> Started working with Weld > 1.1.1 and >>>>>>>> found two issues that probably > should >>> be >>>>> addressed (maybe >>>>>>>> just documented). They both > look to me >>> like >>>>> leaking >>>>>>>> implementation details because > proxies >>> are >>>>> used for >>>>>>>> components which are not > @Singleton >>> or >>>>> @Dependent. >>>>>>>> >>>>>>>> @ApplicationScoped >>>>>>>> public class Bug { >>>>>>>> >>>>>>>> public > Bug() { >>>>>>>> >>>>>>>> >>> System.out.println("########## >>>>>>>> CONSTRUCT"); >>>>>>>> } >>>>>>>> >>>>>>>> public > void foo() { >>>>>>>> >>>>> > System.out.println("##### >>>>>>>> FOO"); >>>>>>>> } >>>>>>>> >>>>>>>> public > static void >>>>> main(String[] args) { >>>>>>>> > Weld weld = >>> new >>>>> Weld(); >>>>>>>> >>> WeldContainer >>>>> weldContainer >>>>>>>> = weld.initialize(); >>>>>>>> >>>>>>>> > Bug bug = >>>>>>>> >>>>> > weldContainer.instance().select(Bug.class).get(); >>> // >>>>> Creates >>>>>>>> new instance of Bug >>>>>>>> > bug.foo(); >>> // >>>>> Creates new >>>>>>>> instance of Bug!!! >>>>>>>> > bug.foo(); >>> // >>>>> Uses existing >>>>>>>> instance >>>>>>>> >>>>>>>> >>>>> weld.shutdown(); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> The proxy of Bug will call > its >>> superclass >>>>> constructor >>>>>>>> several times during the > lifecycle of >>> the Bug >>>>> component. I >>>>>>>> don't know if that is really >>> necessary, but if >>>>> it is, you >>>>>>>> can now no longer use > constructors to >>>>> initialize your >>>>>>>> component. This is an issue > because >>>>>>>> >>>>>>>> - it's not documented that >>> constructors of >>>>>>>> @ApplciationScoped (etc., > proxied) >>> components >>>>> behave >>>>>>>> differently than >>> @Singleton/@Dependent >>>>> constructors >>>>>>>> >>>>>>>> - even if it's documented, > it's >>> questionable >>>>> if that really >>>>>>>> should be the case. >>>>>>>> >>>>>>>> Taking away constructors as > the >>> primary means >>>>> of >>>>>>>> initializing a component - > e.g. >>> obtaining >>>>> resources such as >>>>>>>> database connections, reading > config >>> files, >>>>> etc. - is a >>>>>>>> major change in the Java > programming >>> model. >>>>> Users have to be >>>>>>>> strongly advised to use > @PostConstruct >>> then. >>>>>>>> >>>>>>>> The other issue I immediately > found is >>> also >>>>> related to >>>>>>>> behavior of proxies and how >>> transitive >>>>>>>> initializing/injection is > implemented >>> (not >>>>> sure if this is >>>>>>>> actually specified > somewhere): >>>>>>>> >>>>>>>> @ApplicationScoped >>>>>>>> public class Foo { >>>>>>>> >>>>>>>> > @Inject >>>>>>>> Bar > bar; >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> @ApplicationScoped >>>>>>>> public class Bar { >>>>>>>> >>>>>>>> @Inject >>>>>>>> Baz baz; >>>>>>>> >>>>>>>> >>> @PostConstruct >>>>>>>> void > init() { >>> ... } >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> When I obtain a reference to > Foo, I >>> get a >>>>> proxy of Foo with >>>>>>>> a reference to a proxy of Bar. > The >>> init() >>>>> method of Bar is >>>>>>>> never called. The Baz > component is >>> never >>>>> activated. >>>>>>>> >>>>>>>> This means I can't > transitively >>> initialize an >>>>>>>> application-scoped graph of >>> components. I was >>>>> trying to use >>>>>>>> CDI for wiring in a Swing > application >>> and I >>>>> imagine this >>>>>>>> would be a common usecase. It > should >>> either be >>>>> documented >>>>>>>> that there is a difference > between >>>>> @Singleton/@Dependent and >>>>>>>> proxy-implemented scopes, or >>> unification >>>>> should be >>>>>>>> considered. >>>>>>>> >>> >>> > >

On 24.05.11 21:46 Pete Muir wrote: > On 24 May 2011, at 20:42, Mark Struberg wrote: > >> Imo it is surprising, since it would break all kinds of 'business >> injections' (as opposed to classic 'resource injections' - Jens Schumann >> can explain this well ;) > > Can you make him explain it for our edification? Haha Mark;) Just a brief answer - since I crossed the critical wake period already... What I call 'business injection' (the German term 'fachliche injection' is more precise) shouldn't be any news to you guys. I keep telling my audience that CDI helps me to go beyond classic infrastructure injection towards a more domain / business oriented approach. Instead of injecting data sources, services or DAO's I am able to inject the current user, a selected item or a newly created customer - across application layers. This - in combination with "business driven" event handling [1] - is what I love about CDI;) On 24.05.11 21:24 Pete Muir wrote: >> Thus if you would require all contextual instances being created >> immediately, then you would get a ContextNotActiveException... > > Yes, but this isn't that surprising and the principle of least surprise > is a good one to follow ;-) As Mark said before: Think about the current authenticated user that should be available to infrastructure code. Enforcing all contextual instances being created immediately would kill that feature - as far I understand. Hope that helps, Jens [1] sendWelcomeEmail(@Observes @Created Customer newCustomer) _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

Also the lazy init is imo a well specified and welcome behaviour.