Ich habe die nächste applicationContext.xml Datei im Stammverzeichnis von classpath:
props/datasource.properties existiert auch im Stammverzeichnis des Klassenpfads mit folgendem Inhalt:
Ich habe einen federverwalteten Test, bei dem ich die Verwendung der zuvor erwähnten Datei "applicationContext.xml" über die folgenden Anmerkungen erklären möchte:
%Vor%Wenn ich die Testmethode aufrufe, bekomme ich den nächsten Fehler vom Frühling:
%Vor%Wie ich verstehe, hat sping den Verweis auf jdbc.driverclass nicht aufgelöst. Was habe ich falsch gemacht?
PS: Ich benutze Feder 3.2.3.RELEASE
**
**
Vielleicht liegt das Problem in MapperScannerConfigurer . Es ist ein BeanDefinitionRegistryPostProcessor und wie Javadoc sagt:
Erweiterung des Standard BeanFactoryPostProcessor SPI, Zulassen der Registrierung weiterer Bean-Definitionen bevor die normale BeanFactoryPostProcessor-Erkennung eintritt
So MapperScannerConfigurer instanziiert das Datenquellenobjekt über sqlSessionFactory, wobei BeanFacoryPostProcessor (welches für <context:property-placeholder/> verantwortlich ist) nicht verwendet wurde.
Also meine Frage transformiert, um BeanFacoryPostProcessor von <context:property-placeholder/> und BeanDefinitionRegistryPostProcessor ( MapperScannerConfigurer ) neu zu ordnen?
Nach einigen Stunden der Untersuchung fand ich die Lösung:
Wie bereits erwähnt, ist MapperScannerConfigurer ein BeanDefinitionRegistryPostProcessor , das vor BeanFactoryPostProcessor ausgelöst wird, was für <context:property-placeholder/> verantwortlich ist. Während der Erstellung von MapperScannerConfigurer werden Verweise auf externe Eigenschaften nicht aufgelöst. In diesem Fall müssen wir die Erstellung der Datenquelle auf die Zeit verschieben, nachdem BeanFactoryPostProcessor angewendet wurde. Wir können das auf verschiedene Arten tun:
p:sqlSessionFactory-ref="sqlSessionFactory" von MapperScannerConfigurer . In diesem Fall wird das Datenquellenobjekt nicht vor MapperScannerConfigurer erstellt, sondern nach BeanFactoryPostProcessor , das für <context:property-placeholder/> verantwortlich ist. Wenn Sie mehr als eine sqlSessionFactory in applicationContext haben, können einige Probleme auftreten sqlSessionFactoryBeanName anstelle von sqlSessionFactory zu setzen. Es hilft, das PropertyPlaceHolder-Problem mit BeanFactoryPostProcessor zu lösen. Es ist ein empfohlener Weg, um dieses Problem zu lösen, das im mybatis-spring Dokument beschrieben wird
Ich hatte das gleiche Problem und stieß auf diesen Beitrag, aber ich konnte es nicht auf die gleiche Weise lösen wie maks. Am Ende funktionierte es für mich, den ignoreUnresolvablePlaceholders-Eigenschaftswert auf true zu setzen.
%Vor%Ich benutze auch Spring 3.2.3.RELEASE. Ich weiß, dass dieser Beitrag über 4 Monate alt ist, aber ich denke, dass jemand es nützlich finden könnte.
Kurzform: Was ist der richtige Weg, um eine Implementierung von: BeanDefinitionRegistryPostProcessor zu laden?
Erweiterte Form: Gibt es eine Möglichkeit, BeanDefinitionRegistryPostProcessor zu laden, bevor irgendwelche Beans erstellt wurden. Wenn Sie das Javadoc betrachten:
Erweiterung auf den Standard {@ Link BeanFactoryPostProcessor} SPI unter Berücksichtigung von die Registrierung weiterer Bean-Definitionen vor regulär Die BeanFactoryPostProcessor-Erkennung wird gestartet.
Es ist also beabsichtigt, geladen zu werden, wenn Bean-Definitionen erstellt wurden, aber bevor irgendwelche Beans erstellt wurden. Wenn wir es nur als reguläre Bean in der Anwendung xml erstellen, wird der Zweck, diese Bean überhaupt zu verwenden, nicht erfüllt.