Re: [Springframework-developer] Reworked root/child bean definition concept

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

Yes, for example this makes TransactionProxyFactoryBean attractive again 
compared to BeanNameAutoProxyCreator to do transactional wrapping, even 
for the simplere cases of almost identical setup.


Rod Johnson wrote:

>I like this. Actually the Interface21 framework had something 
>closer to this (although parent class couldn't be changed). 
>It's certainly useful for templating. 
>
>For example, this might be used to set up a ProxyFactoryBean 
>for repeated use, allowing subclasses to set target and 
>(optionally) override advice.
>
>Capturing such reused information in one place is definitely 
>desirable.
>
>Rod
>
>---- Original message ----
>  
>
>>Date: Thu, 24 Jun 2004 16:43:44 +0200
>>From: jürgen höller [werk3AT] <jue...@we...>  
>>Subject: [Springframework-developer] Reworked root/child 
>>    
>>
>bean definition concept  
>  
>
>>To: <spr...@li...>
>>
>>I've just committed a fairly significant reworking of our 
>>    
>>
>root/child bean definition concept: A child can now inherit 
>respectively override virtually any attributes from a parent, 
>not just bean property values and the singleton flag. From 
>the new ChildBeanDefinition javadoc:
>  
>
>>* <p>Will use the bean class of the parent if none 
>>    
>>
>specified, but can
>  
>
>>* also override it. In the latter case, the child bean 
>>    
>>
>class must be
>  
>
>>* compatible with the parent, i.e. accept the parent's 
>>    
>>
>property values
>  
>
>>* and constructor argument values, if any.
>>*
>>* <p>A child bean definition will inherit constructor 
>>    
>>
>argument values,
>  
>
>>* property values and method overrides from the parent, 
>>    
>>
>with the option
>  
>
>>* to add new values. If init method, destroy method and/or 
>>    
>>
>static factory
>  
>
>>* method are specified, they will override the 
>>    
>>
>corresponding parent settings.
>  
>
>>*
>>* <p>The remaining settings will <i>always</i> be taken 
>>    
>>
>from the child definition:
>  
>
>>* depends on, autowire mode, dependency check, singleton, 
>>    
>>
>lazy init.
>  
>
>>Everything that worked before still works; it should be 
>>    
>>
>fully backward compatible. Formerly, this mechanism has 
>mainly been used for view definitions; there's just a much 
>wider range of usage scenarios now, for example:
>  
>
>> <bean id="inheritedTestBean" 
>>    
>>
>class="org.springframework.beans.TestBean">
>  
>
>>   <property name="name"><value>parent</value></property>
>>   <property name="age"><value>1</value></property>
>> </bean>
>>	
>> <bean id="inheritsWithDifferentClass" 
>>    
>>
>class="org.springframework.beans.DerivedTestBean"
>  
>
>>     parent="inheritedTestBean" init-method="initialize">
>>   <property name="name"><value>override</value></property>
>>   <!-- age should inherit value of 1 from parent -->
>> </bean>
>>
>>The child class above uses a different bean class and init 
>>    
>>
>method, but still inherits the property values from the 
>parent. Alternatively, the parent can even omit the bean 
>class completely, simply specifying common properties for 
>children:
>  
>
>> <bean id="inheritedTestBeanWithoutClass">
>>   <property name="name"><value>parent</value></property>
>>   <property name="age"><value>1</value></property>
>> </bean>
>>
>> <bean id="inheritsWithClass" 
>>    
>>
>class="org.springframework.beans.DerivedTestBean"
>  
>
>>     parent="inheritedTestBeanWithoutClass" init-
>>    
>>
>method="initialize">
>  
>
>>   <property name="name"><value>override</value></property>
>>   <!-- age should inherit value of 1 from parent -->
>> </bean>
>>
>>Of course, such a parent bean cannot get instantiated on its 
>>    
>>
>own: It's just a template that serves as parent definition 
>for children. preInstantiateSingletons will ignore such beans 
>without class and parent completely.
>  
>
>>I'm aware that this is a significant change in concept, but 
>>    
>>
>I've experienced repeatedly that this is what users expect it 
>work like - being surprised that all they could do was 
>overriding bean property values. A colleague of mine has a 
>current use case that I've changed this for.
>  
>
>>If there any suggestions or objections, feel free to voice 
>>    
>>
>them - before 1.1 RC1 :-)
>  
>
>>Juergen
>>
>>
>>DI Jürgen Höller
>>Senior System Architect
>>______________________________________
>>
>>werk3ATS - division systementwicklung
>>werk3AT informations- und mediensysteme
>>
>>europaplatz 4
>>A - 4020 linz
>>
>>t.  +43 (0) 732 71 65 29 502
>>f.  +43 (0) 732 71 65 29 3
>>mailto:jue...@we...
>>http://www.werk3at.com
>>______________________________________
>>werk3ATS - WIR ENTWICKELN ERFOLG
>>
>>
>>-------------------------------------------------------
>>This SF.Net email sponsored by Black Hat Briefings & 
>>    
>>
>Training.
>  
>
>>Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>>    
>>
> 
>  
>
>>digital self defense, top technical experts, no vendor 
>>    
>>
>pitches, 
>  
>
>>unmatched networking opportunities. Visit www.blackhat.com
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-
>>    
>>
>developer
>  
>