Menu
▾
▴
springframework-developer
|
From: Juergen H. <ju...@in...> - 2006-06-19 07:12:53
|
You mean a setting at the application context level that determines the lazy-init semantics? Where would you specify that? I guess in the end it comes down to tweaking the XML bean definition files again... Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Erwin Vervaet Sent: Monday, June 19, 2006 9:18 AM To: spr...@li... Subject: Re: [Springframework-developer] Changed behavior fordefault-lazy-init="true" in 2.0 M5 Absolutely. Maybe we should have a setting to switch to Spring 1.x lazy-init semantics? Erwin Vervaet erw...@er... ----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...> To: <spr...@li...> Sent: Monday, June 19, 2006 2:01 AM Subject: Re: [Springframework-developer] Changed behavior for default-lazy-init="true" in 2.0 M5 >I think this makes sense, personally, although it does mean most apps >marked with the default lazy init set to true will probably have to >have their config tweaked. I guess we need to really emphasize this >change in the change docs. > > Colin > > On 6/18/2006 7:40 PM, Juergen Hoeller wrote: > >>This is actually expected behavior: lazy-init has stronger effect in >>Spring 2.0 now, not even loading the affected bean classes until they >>are explicitly accessed. >> >>For an application context's type detection (such as >>BeanFactoryPostProcessor detection or ApplicationListener detection), >>we only check beans that allow for eager initialization now (i.e. that >>are not marked as lazy-init and are not FactoryBeans). >> >>Else we'd have to load each and every bean class just to find out >>those special beans, which would require all bean classes to be >>present and loadable - and exactly that is what we intend to avoid >>with the new semantics in the first place. >> >>A further goodie enabled by lazy class loading for lazy-init beans is >>that a PropertyPlaceholderConfigurer can even resolve placeholders in >>bean class names now, at least for beans marked as lazy-init. >> >>So the recommended solution in case of default-lazy-init=true would be >>to explicitly mark all affected beans (the ones supposed to be >>autodetected) as lazy-init=false. >> >>Juergen >> >> >>-----Original Message----- >>From: spr...@li... >>[mailto:spr...@li...] On >>Behalf Of Claus Nordahl >>Sent: Sunday, June 11, 2006 2:26 AM >>To: spr...@li... >>Subject: [Springframework-developer] Changed behavior for >>default-lazy-init="true" in 2.0 M5 >> >>Hi all, >> >>When using default-lazy-init="true" with the 2.0 M5 release, I find >>that neither does my PropertyPlaceholderConfigurer's do its stuff nor >>does my ApplicationListener's receive any events as they all did with >>previous releases. >> >>Is this expected behavior? >> >>Regards, >>Claus Nordahl >> >> >> >> >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> > > > > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Juergen H. <ju...@in...> - 2006-06-21 21:13:34
|
Indeed... although I wonder why you passed in "false" as the last argument there in the first place. After all, the main reason to pass "false" in there was to avoid eager initialization of FactoryBeans... For a significant portion of typical Spring apps, this shouldn't make much difference (at least I hope so), since the intent of the original flag is still somewhat similar to the new semantics. Still, point taken - we need to clearly document this. It is a change in semantics for applications that either rely on default-lazy-init for all beans or make use of the getBeansOfType variant with "false" as last argument. Unfortunately, there was no other way to provide the desired behavior for lazy loading of bean classes. The main goal was to not have standard getBeansOfType calls trigger the loading of all bean classes defined in the context. Hope the migration was still smooth enough for you... Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Matt Sgarlata Sent: Wednesday, June 21, 2006 11:02 PM To: spr...@li... Subject: Re: [Springframework-developer] Changed behavior fordefault-lazy-init="true" in 2.0 M5 This also changes the behavior of ListableBeanFactory.getBeansOfType(Class, boolean, false). In Spring 1.x this method would return beans that had lazy-init="true" but in Spring 2.x this method does not reutrn beans with lazy-init="true". This has been the largest source of migration headaches for me in my application. Matt Colin Sampaleanu wrote: > I think this makes sense, personally, although it does mean most apps > marked with the default lazy init set to true will probably have to > have their config tweaked. I guess we need to really emphasize this > change in the change docs. > > Colin > > On 6/18/2006 7:40 PM, Juergen Hoeller wrote: > >> This is actually expected behavior: lazy-init has stronger effect in >> Spring 2.0 now, not even loading the affected bean classes until they >> are explicitly accessed. >> >> For an application context's type detection (such as >> BeanFactoryPostProcessor detection or ApplicationListener detection), >> we only check beans that allow for eager initialization now (i.e. >> that are not marked as lazy-init and are not FactoryBeans). >> >> Else we'd have to load each and every bean class just to find out >> those special beans, which would require all bean classes to be >> present and loadable - and exactly that is what we intend to avoid >> with the new semantics in the first place. >> >> A further goodie enabled by lazy class loading for lazy-init beans is >> that a PropertyPlaceholderConfigurer can even resolve placeholders in >> bean class names now, at least for beans marked as lazy-init. >> >> So the recommended solution in case of default-lazy-init=true would >> be to explicitly mark all affected beans (the ones supposed to be >> autodetected) as lazy-init=false. >> >> Juergen >> >> >> -----Original Message----- >> From: spr...@li... >> [mailto:spr...@li...] On >> Behalf Of Claus Nordahl >> Sent: Sunday, June 11, 2006 2:26 AM >> To: spr...@li... >> Subject: [Springframework-developer] Changed behavior for >> default-lazy-init="true" in 2.0 M5 >> >> Hi all, >> >> When using default-lazy-init="true" with the 2.0 M5 release, I find >> that neither does my PropertyPlaceholderConfigurer's do its stuff nor >> does my ApplicationListener's receive any events as they all did with >> previous releases. >> >> Is this expected behavior? >> >> Regards, >> Claus Nordahl >> >> >> >> >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-develope >> r >> >> >> >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-develope >> r >> >> >> All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Matt S. <mat...@sp...> - 2006-06-21 21:29:34
|
I understand the reasoning, and I am glad to see Spring is being more aggressive in how lazily things are initialized. I just wanted to point out a place where documentation could use some clarification. I was indeed putting in false as the last argument to avoid eager initialization of FactoryBeans. In particular, if true was passed in instead of false, that meant if I called getBeansOfType or getBeanNamesForType from a BeanFactoryPostProcessor, it would prematurely cause the initialization of FactoryBeans and therefore prevent other BeanFactoryPostProcessors from applying to those FactoryBeans. So far I haven't run into any roadblocks because of this change, but I'll certainly let you know if I do :) It may be the case that a fourth argument is needed to specify whether or not to search lazy-init objects separately from whether to search FactoryBeans for this reason, but I have not yet run into such a use case. Migration has been pretty smooth for me, except that the Quartz SchedulerFactoryBean does not seem to like being proxied anymore. http://opensource.atlassian.com/projects/spring/browse/SPR-2169 Matt Juergen Hoeller wrote: > Indeed... although I wonder why you passed in "false" as the last argument > there in the first place. After all, the main reason to pass "false" in > there was to avoid eager initialization of FactoryBeans... > > For a significant portion of typical Spring apps, this shouldn't make much > difference (at least I hope so), since the intent of the original flag is > still somewhat similar to the new semantics. > > Still, point taken - we need to clearly document this. It is a change in > semantics for applications that either rely on default-lazy-init for all > beans or make use of the getBeansOfType variant with "false" as last > argument. > > Unfortunately, there was no other way to provide the desired behavior for > lazy loading of bean classes. The main goal was to not have standard > getBeansOfType calls trigger the loading of all bean classes defined in the > context. > > Hope the migration was still smooth enough for you... > > Juergen > > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On Behalf > Of Matt Sgarlata > Sent: Wednesday, June 21, 2006 11:02 PM > To: spr...@li... > Subject: Re: [Springframework-developer] Changed behavior > fordefault-lazy-init="true" in 2.0 M5 > > This also changes the behavior of > ListableBeanFactory.getBeansOfType(Class, boolean, false). In Spring 1.x > this method would return beans that had lazy-init="true" but in Spring 2.x > this method does not reutrn beans with lazy-init="true". > > This has been the largest source of migration headaches for me in my > application. > > Matt > > Colin Sampaleanu wrote: >> I think this makes sense, personally, although it does mean most apps >> marked with the default lazy init set to true will probably have to >> have their config tweaked. I guess we need to really emphasize this >> change in the change docs. >> >> Colin >> >> On 6/18/2006 7:40 PM, Juergen Hoeller wrote: >> >>> This is actually expected behavior: lazy-init has stronger effect in >>> Spring 2.0 now, not even loading the affected bean classes until they >>> are explicitly accessed. >>> >>> For an application context's type detection (such as >>> BeanFactoryPostProcessor detection or ApplicationListener detection), >>> we only check beans that allow for eager initialization now (i.e. >>> that are not marked as lazy-init and are not FactoryBeans). >>> >>> Else we'd have to load each and every bean class just to find out >>> those special beans, which would require all bean classes to be >>> present and loadable - and exactly that is what we intend to avoid >>> with the new semantics in the first place. >>> >>> A further goodie enabled by lazy class loading for lazy-init beans is >>> that a PropertyPlaceholderConfigurer can even resolve placeholders in >>> bean class names now, at least for beans marked as lazy-init. >>> >>> So the recommended solution in case of default-lazy-init=true would >>> be to explicitly mark all affected beans (the ones supposed to be >>> autodetected) as lazy-init=false. >>> >>> Juergen >>> >>> >>> -----Original Message----- >>> From: spr...@li... >>> [mailto:spr...@li...] On >>> Behalf Of Claus Nordahl >>> Sent: Sunday, June 11, 2006 2:26 AM >>> To: spr...@li... >>> Subject: [Springframework-developer] Changed behavior for >>> default-lazy-init="true" in 2.0 M5 >>> >>> Hi all, >>> >>> When using default-lazy-init="true" with the 2.0 M5 release, I find >>> that neither does my PropertyPlaceholderConfigurer's do its stuff nor >>> does my ApplicationListener's receive any events as they all did with >>> previous releases. >>> >>> Is this expected behavior? >>> >>> Regards, >>> Claus Nordahl >>> >>> >>> >>> >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> https://lists.sourceforge.net/lists/listinfo/springframework-develope >>> r >>> >>> >>> >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> https://lists.sourceforge.net/lists/listinfo/springframework-develope >>> r >>> >>> >>> > > > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 |
