Re: [Springframework-developer] Changed behavior fordefault-lazy-init="true" in 2.0 M5

[Juergen H. <ju...@in...>]

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