Sinon l’alias dataSource est injecté ainsi :
[xml]
<bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean" depends-on="dataSource">
<description>
Factory hibernate qui va nous permettre de récupérer des sessions.
On lui passe la "underlying jdbc datasource" (lien jdbc avec la base)
ainsi que le gestionnaire de transactions (pas besoin de JTA ici
puisqu’on a une seule source de donnée, la base postgres).
</description>
<property name="dataSource" ref="dataSource"/>
<property name="configLocation">
<value>classpath:hibernate.cfg.xml</value>
</property>
</bean>
[/xml]

Enfin la sessionFactory est injecté dans le constructeur un kebabDao qui lui-même est utilisé dans un kebabService.

Une autre variante plus simple est au lieu d’importer des fichiers de configuration différents (ici un dataSourceTest en test ), c’est d’importer le fichier utilisé par le serveur & de redéfinir le bean du même nom.

Ceci est possible en important un autre fichier
qui possède un bean du même nom. Et le dernier qui est trouvé par Spring est retenu.

Exemple: un test unitaire importe :
– appplicationContext.xml qui lui importe tout (dont un bean appelé monSuperDataSource)
- plus un dataSourceTest.xml qui définit un bean appelé monSuperDataSource. Etant le dernier importé du meme nom, c’est lui qui sera injecté par Spring.

C’est aussi utile pour importer par redéfinition des beans mockés qui n’attaquent pas un ldap, si externe etc. mais retourne des valeurs quelconques car hors scope du test.

Merci d’être repassé pour les précisions

Or mon commentaire faisait référence uniquement à la classe JndiDatasourceCreator
qui peut etre pourrait utiliser un properties mais ce n’est pas le cas dans l’exemple où les paramètres sont codés en static.

Mon jndi est défini dans un fichier datasourceContext.xml :
[xml]
<bean id="tomcatDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="resourceRef" value="true"/>
<property name="jndiName">
<value>java:comp/env/jdbc/ScribeDB</value>
</property>
</bean>
<alias alias="dataSource" name="tomcatDataSource"/>
[/xml]

Et durant les tests unitaires, j’importe en lieu et place de ce
dernier un dataSourceTest.xml au contenu suivant :
[xml]
<!–
Création de la dataSource
ici une connexion jdbc vers la base données
–>
<bean id="testDataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="org.postgresql.Driver"/>
<property name="url" value="%{dataSource.url}"/>
<property name="username" value="%{dataSource.username}"/>
<property name="password" value="%{dataSource.password}"/>
</bean>
<alias alias="dataSource" name="testDataSource"/>
[/xml]

Voila.

Dans les tests unitaire j’importe un autre fichier xml: dataSourceTest.xml à la palce du précédent

Concernant la seconde solution proposée, elle a l’inconvénient d’internaliser la configuration dans du code java

java:comp/env/jdbc/appDB

Pour mes tests unitaires, je ne charge pas ce fichier mais un autre datasourceTest.xml