Wir haben eine Hierarchie von Handler-Klassen in unserer Codebasis, die eine Art von Verantwortung-Prinzip implementieren. Es ist eine abstrakte Superklasse und sie von mehreren untergeordneten Klassen erweitert, die auch die Zusammenfassung in ihrem Konstruktor erhaltenVerwenden Sie abstrakte Spring Bean als Konstruktor-Arg
public abstract class AbstractHandler {
public AbstractHandler(final AbstractHandler next, final PropertyName propertyName) {
this.next = next;
this.propertyName = propertyName;
}
...
public class OneConcreteChildHandler extends AbstractHandler {
public OneConcreteChildHandler(final AbstractHandler next) {
super(next, PropertyName.OneConcreteChild);
}
...
Wir würden jetzt eine Instanz eines der konkreten Kind-Klassen in einen neu implementierten Service injizieren müssen Klasse, und wir sollten dies in XML konfigurieren. Wir können eine abstrakte Bohne für die abstrakte Superklasse konfigurieren, aber diese dann scheint nicht für die konkrete Kind bean
<bean id="abstractHandler" abstract="true" class="...AbstractHandler" />
<bean id="oneConcreteChildHandler" class="...OneConcreteChildHandler" parent="abstractHandler">
<constructor-arg ref="abstractHandler"/> //"abstract bean can not be used here"
</bean>
<bean id="someService" class="...SomeService">
<constructor-arg ref="oneConcreteChildHandler"/>
...
Gibt es eine Möglichkeit, dies zu überwinden als Konstruktor-Arg- verwendet werden soll erlaubt zu sein? Die Handlerklassenhierarchie ist Legacy-Code und wir können ihre Quellen zu diesem Zeitpunkt nicht ändern.
Vielen Dank. Wir haben gerade bemerkt, dass es unter den konkreten Child-Klassen tatsächlich eine TailChildHandler-Klasse zum Schließen der CoR-Kette gibt (ihr Konstruktor enthält super (null, null)) und wir können sie in der config auf die gleiche Weise wie twoConcreteChildHandler in Ihrem verwenden Beispiel. Dies behebt das Problem. – hammerfest