Re: [Springframework-developer] reloading/hot swapping of beans

[Colin S. <col...@ex...>]

There are two aspects related to the fact that you wrap an object in a 
dynamic proxy (java or cglib generated) like this. I only mentioned 
hotswapping in the message below, but I had talked about the other in a 
previous message, that is the fact that you can effectively accomplis 
lazy loading of the bean, or set of beans, very easily.

Because this is so much related to lifecycle, there are arguments for 
making this a standard part of the bean definition in the context (i.e. 
part of the dtd). The only issue right now is that there is a shared dtd 
for bean factories and contexts.

My gut feeling is that some things are very well handled by 
BeanPostProcessor, when it's doing something orthogonal to the bean 
lifecycle, but when the lifecycle of the bean is being touched like 
this, it's at least worth thinking about if the container should be 
involved...



Rod Johnson wrote:

>I've just added a HotSwappableInvokerInterceptor that allows such swapping
>for advised objects. I think it's better to do this via AOP than via an ad
>hoc DP solution. This way it will work for classes proxied by CGLIB also.
>
>As I said in a previous message, I don't think this should be the default.
>
>I'm thinking of ways to enable this. A BeanPostProcessor is the obvious
>approach.
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Monday, November 17, 2003 8:21 PM
>Subject: [Springframework-developer] reloading/hot swapping of beans
>
>
>  
>
>>This is only of use in certain scenarios, but we should maybe examine
>>the possibilities w/regards to unloading and reloading of beans. Both
>>HiveMind and now Pico
>>  http://www.picocontainer.org/hotswapping.html
>>allow reloading of a bean/component returned from the container, due to
>>the fact they they automatically introduce a dynamic proxy for the
>>object returned form the container.
>>
>>This has a slight performance impact, but is probably the easiest way to
>>handle reloading. Now how much additional
>>complexity/variability/breakage this could introduce is I think pretty
>>hard to figure out, given the amount of stuff you can do now with things
>>like the BeanPostProcessor which can affect the lifecycle of a bunch of
>>things in the container.
>>    
>>