2010-11-14 3 views
3

J'ai une application web, basée sur Spring 3.0.3, que j'ai développée avec Eclipse 3.4. Ce faisant, j'ai exécuté l'application Web dans Tomcat 6.0.18 d'Eclipse. En d'autres termes, Eclipse utilise l'installation de Tomcat, ce qui signifie que Tomcat, au besoin, modifiera les fichiers, etc. (au moins, c'est ce que je comprends de ce qu'il fait).Problèmes avec classpath entre Eclipse, Tomcat et JUnit dans l'application Spring 3

Mon problème est de spécifier les valeurs de contextConfigLocations dans le fichier web.xml. Lors de l'exécution à partir d'Eclipse cela a bien fonctionné:

<context-param> 
    <param-name>contextConfigLocation</param-name> 
    <param-value> 
     classpath:applicationContext.xml 
     classpath:applicationContext-security.xml 
    </param-value> 
</context-param> 

Cependant, quand j'empaquette l'application dans un fichier de guerre (ROOT.war), puis ajouté à répertoire webapp de Tomcat et essayez de démarrer Tomcat, je reçois un erreur qu'aucun de ces fichiers applicationContext ne peut être trouvé. Mais quand je le change ci-dessous, Tomcat peut trouver les fichiers:

<context-param> 
    <param-name>contextConfigLocation</param-name> 
    <param-value> 
     /WEB-INF/config/applicationContext.xml 
     /WEB-INF/config/applicationContext-security.xml 
    </param-value> 
</context-param> 

Je dois souligner que applicationContext.xml inclut d'autres fichiers applicationContext qui utilisent également le classpath: sténo. Lors de l'exécution dans Tomcat, je dois abandonner toute utilisation de classpath: en faveur des chemins relatifs pour que Tomcat puisse voir ces fichiers.

Très bien. Tomcat et Eclise s'entendent bien. Mais JUnit 4.7 n'est plus content. Pour une raison quelconque, les fichiers spécifiés à l'aide de @ContextConfiguration dans une classe de test ne peuvent pas être trouvés à moins que classpath: short hand soit utilisé. Voici un exemple:

@ContextConfiguration(locations = {"classpath:applicationContext.xml", "classpath:applicationContext-security.xml"}) 
public class UserDaoTest extends AbstractTransactionalJUnit4SpringContextTests { 

    @Test 
    public void testCreateUser() { 
    } 

Alors applicationContext.xml et applicationContext-security.xml se trouvent sans problème; toutefois, les fichiers de propriétés spécifiés dans applicationContext.xml sont introuvables. Mais si je spécifie l'emplacement de ces fichiers en utilisant le classpath: short hand, les fichiers de propriétés sont trouvés. Si je fais cela cependant, les fichiers ne seront pas trouvés lors de l'exécution à partir d'un fichier war dans Tomcat.

Pour l'instant j'ai créé un applicationContext-test.xml qui est un conglomérat de copier-coller de tous les autres fichiers applicationContext dans lesquels j'utilise le classpath: short hand. Cela semble haineux et sujet à erreur et je me demande quel pourrait être le problème dans toutes ces technologies.

Vos commentaires sont les bienvenus!

Répondre

2

contenu web.xml devrait ressembler à

<context-param> 
    <description> 
       Spring Context Configuration. 
      </description> 
    <param-name>contextConfigLocation</param-name> 
    <!-- spring loads all --> 
    <param-value> 
       classpath*:spring/*.xml, 
       classpath*:spring/persistence/*.xml, 
       classpath*:spring/webapp/*.xml</param-value> 
    </context-param> 

voir http://static.springsource.org/spring/docs/2.5.x/reference/resources.html#resources-app-ctx-wildcards-in-resource-paths pour référence ultérieure

la config JUnit devrait suivre la même convention avec classpath *:

mais méfiez-vous du printemps pourrait charger .xml les fichiers de contexte que vous ne voulez pas faire

+0

l'ordre n'a pas d'importance? êtes-vous sûr?? il n'est donc pas possible d'écraser une définition de bean dans un autre fichier de configuration? –

+0

pour la liste de valeur de paramétre l'ordre n'a pas d'importance, le ressort charge tout, mais je vais ajuster le commentaire, pour le réécriture du bean, c'est certainement important, mais je ne compterais pas sur le comportement déterministe –