Menu
▾
▴
springframework-developer
|
From: Rod J. <rod...@in...> - 2004-06-24 15:47:14
|
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 on= e place is definitely = desirable. Rod ---- Original message ---- >Date: Thu, 24 Jun 2004= 16:43:44 +0200 >From: j=FCrgen h=F6ller [werk3AT] <juergen.hoeller@wer= k3at.com> = >Subject: [Springframework-developer] Reworked root/child = bean definition concept = >To: <spr...@li...> > >I've just co= mmitted 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 pare= nt, = with the option > * to add new values. If init method, destroy method a= nd/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 ch= eck, 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=3D"inhe= ritedTestBean" = class=3D"org.springframework.beans.TestBean"> > <property name=3D"na= me"><value>parent</value></property> > <property name=3D"age"><value= >1</value></property> > </bean> > = > <bean id=3D"inheritsWithDifferentClass" = class=3D"org.springframework.beans.DerivedTestBean" > parent=3D"in= heritedTestBean" init-method=3D"initialize"> > <property name=3D"nam= e"><value>override</value></property> > <!-- age should inherit valu= e of 1 from parent --> > </bean> > >The child class above uses a dif= ferent 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=3D"inheritedTestBeanWithoutClass"> > <prop= erty name=3D"name"><value>parent</value></property> > <property name= =3D"age"><value>1</value></property> > </bean> > > <bean id=3D"inhe= ritsWithClass" = class=3D"org.springframework.beans.DerivedTestBean" > parent=3D"in= heritedTestBeanWithoutClass" init- method=3D"initialize"> > <proper= ty name=3D"name"><value>override</value></property> > <!-- age shoul= d 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 signi= ficant 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 suggestio= ns or objections, feel free to voice = them - before 1.1 RC1 :-) > >Juergen > > >DI J=FCrgen H=F6ller >Se= nior System Architect >______________________________________ > >werk= 3ATS - division systementwicklung >werk3AT informations- und mediensyst= eme > >europaplatz 4 >A - 4020 linz > >t. +43 (0) 732 71 65 29 502= >f. +43 (0) 732 71 65 29 3 >mailto:jue...@we... >htt= p://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 mailin= g list >Spr...@li... >https://lists= .sourceforge.net/lists/listinfo/springframework- developer |
|
From: Colin S. <col...@ex...> - 2004-06-24 16:26:13
|
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 > > |
