Tomcat 7 et fichier de context

Version imprimable

03/10/2013, 21h28
Invité

Tomcat 7 et fichier de context

Bonjour.

Sur mon environnement de dévelopement, j'ai un tomcat 5.
Je peux donc avoir mon application appli.war contenant un fichier context.xml dans le meta-inf.

Au deploiement, celui est automatiquement mis par tomcat dans conf/catalina/localost/monappli.xml
--> ma connexion à la bdd fonctionne donc

Sur le serveur sur lequel je dois déployer, j'ai un tomcat 7.
Notre service d'exploitation souhaite que le fichier de context soit "externe" au war afin de pouvoir changer de base indépendamment du war.
1/si je leur met à disposition un war "sans fichier de context", et met mannuellement le fichier dans conf/catalina/localost/monappli.xml,
--> la connexion ne marche pas. (cela fonctionne sur un tomcat 5)

2/si je leur met à disposition un war "avec fichier de context", le war se dezippe, mais aucun fichier de context n'est mis automatiquement dans conf/catalina/localost/
--> la connexion fonctionne

Sauriez vous pourquoi sur le point 1, il y a une différence de fonctionnement entre tomcat 5 et 7?

Merci d'avance
03/10/2013, 22h34
tchize_

Parce que entre tromcat 5 et 7 il y a eu énormément de changements et 9 ans d'écart?

La première chose à faire c'est coté dev, d'utiliser le même tomcat que la prod, et pas tomcat 5.

Ensuite, le fichier a gardé le même nommage:

$CATALINA_BASE/conf/[enginename]/[hostname]/[appli].xml

Mais, est-ce que le tomcat 7 tourne bien sur localhost? Il ne tournerais pas plutot sur un nom de domaine précis? Faut voir ce qui se trouve dans la config du tomcat 7 comme hostname.
04/10/2013, 08h07
Invité

En effet, c'est mieurx de développer dans la version.
Je développe sur tomcat 5 car c'est la version "standard" chez nous.

Par contre, dans mon cas, je souhaite rajouter une appli sur un autre serveur qui lui est en 7 (on ne maîtrise pas l'install de ce tomcat car c'est un progiciel livré avec son tomcat).

Oui, c'est bien du localhost.
Il y a bien dans le dossier :
$CATALINA_BASE/conf/catalina/localhost/[appli].xml un fichier contenant le nom de l'appli avec le progiciel. Celui-ci contient les param jdbc de ce progiciel (avec un parametre "crossContext" que je ne connais pas.

C'est pour cela que je m'étonne que mon xml ne soit pas pris en compte...

Merci
04/10/2013, 09h48
tchize_

Citation:

Envoyé par johannsan

Je développe sur tomcat 5 car c'est la version "standard" chez nous.

A partir du moment ou vous supportez aussi un tomcat 7, faudra se mettre à tomcat 7 aussi chez les dev. Et lancer les tests d'intégration à la fois sur tomcat 5 & tomcat 7 lors de la compil. Ca devrait être la première chose à faire.

Tomcat 7 ne fait pas tourner la même spec jav que tomcat 5. Ca veux dire que, a priori, tu risque d'avoir des changement à faire dans ton web.xml.[/QUOTE]

La première chose à faire c'est d'avoir une installe locale de tomcat 7 chez toi et d'y faire tourner l'appli. Ensuite tu pourra donner à ton client les instructions pour le déploiement. Et pas l'inverse.

Bonjour.

Pour votre information, et suite à votre précédente remarque, j'ai installé un tomcat 7 sur le poste de DEV (installation standard).

Je remarque, qu'en tomcat 5, tomcat prend automatiquement le xml présent dans le dossier décompressé du war pour le mettre dans conf\Catalina\localhost
Si celui n'est pas dans le war, on a donc la possibilité de mettre le fichier de context manuellement dans conf\Catalina\localhost

En tomcat 7 : (poste de dev)
Cas 1 /
Le fichier de context reste dans le dossier du war dézippé, mais ne va pas automatiquement dans conf/catalina/localhost
Au démarrage, il y a ce message :
Code:

1 2 3 4 INFO: Starting Servlet Engine: Apache Tomcat/7.0.29 4 oct. 2013 12:18:33 org.apache.catalina.startup.HostConfig deployWAR INFO: Déploiement de l'archive T:\Apache Software Foundation\Tomcat 7.0\webapps\DMIST.war de l'application web 4 oct. 2013 12:18:41 org.apache.catalina.startup.HostConfig deployDirectory
Cas 2/
Si je livre un war sans fichier de context,et que je dépose un fichier de context (au nom de l'appli dans conf\Catalina\localhost) comme le souhaite notre exploitation
--> Le fichier est bien reconnu et la conenxion à la BDD fonctionne

Cas 3/
Mes chose que le cas 2 sur le serveur
--> Le fichier de context n'est pas reconnu et la conenxion à la BDD ne fonctionne pas .
J'ai donc l'erreur :
Code:

1 2 2013-10-04 12:29:29,269 ERROR dmist.dao.services.GestionConnexion - org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC driver of class '' for connect URL 'null' at org.apache.tomcat.dbcp.dbcp.BasicDataSource.createConnectionFactory(BasicDataSource.java:1452)
Je suppsoe donc qu'il y a un paramétrage possible sur le serveur pour que ca marche non?

04/10/2013, 13h32
tchize_

Je vois que ton war contient des majuscules. La casse est bien la même pour le fichier xml? (DMIST.xml et pas dmist.xml)?

Et dans le fichier DMIST.xml, le nom de l'application est bien DMIST et pas dmist?

Tout doit être cohérent. Mais si tu fais tes devs sous windows, vu que le filesystem s'en fout de la casse, tu ne remarquera pas ces erreurs.

le projet eclipse s'appelle DMIST
J'appelle bien l'application par cette URL (exemple sur mon poste) : http://localhost:8080/DMIST/

Le fichier META-INF/context.xml contient :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
<?xml version="1.0" encoding="UTF-8"?>
<Context docBase="DMIST" path="/" reloadable="true" >
	<Resource name="jdbcdmist" auth="Container"
              type="javax.sql.DataSource" 
              driverClassName="oracle.jdbc.driver.OracleDriver"
              url="jdbc:oracle:thin:@IP:1521:SID"
              username="user" 
              password="mdp" 
              maxActive="20" 
              maxIdle="10"
              maxWait="-1">
	</Resource>
</Context>

Si je le mets manuellement dans Catalina/localhost, je le fait bien sous le nom "DMIST.xml"

Je ne sais pas si cela peut avoir un lien, mais dans le dossier catalina/localhost/, il y a déjà un fichier hra.xml sans contexte "avec docbase" contenant :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<Context crossContext="true">
 
  <Realm className="org.apache.catalina.realm.JAASRealm"
         appName="Jetspeed"
         userClassNames="org.apache.jetspeed.security.impl.UserPrincipalImpl"
         roleClassNames="org.apache.jetspeed.security.impl.RolePrincipalImpl"
         useContextClassLoader="true"
         debug="0"/>
 
 
	<Resource name="jdbc/jetspeed" auth="Container"
            factory="org.apache.commons.dbcp.BasicDataSourceFactory"
            type="javax.sql.DataSource" username="user" password="mdp"
            driverClassName="oracle.jdbc.driver.OracleDriver" url="jdbc:oracle:thin:@ip:1521:sid"
            maxActive="100" maxIdle="30" maxWait="10000"/> 
 
	<Valve className="org.apache.catalina.authenticator.FormAuthenticator" characterEncoding="UTF-8"/>
 
</Context>

04/10/2013, 14h24
tchize_
Citation:
Envoyé par johannsan

le projet eclipse s'appelle DMIST
J'appelle bien l'application par cette URL (exemple sur mon poste) : http://localhost:8080/DMIST/

Le fichier META-INF/context.xml contient :

Code:

1 2 <?xml version="1.0" encoding="UTF-8"?> <Context docBase="DMIST" path="/" reloadable="true" >
Il y a une contradiction là. Si tu veux y accéder par /DMIST, le path doit être /DMIST

Aussi, question conne, le tomcat de prod, il aurait pas été reconfiguré pour aller chercher ses contextes ailleurs? Faudrait voir son catalina.conf et son server.xml si possible.

1 pièce(s) jointe(s)

Suite à votre réponse, j'ai remplacé dans META-INF/context.xml
Code:

1 2 3 4 5 6 7 <?xml version="1.0" encoding="UTF-8"?> <Context docBase="DMIST" path="/" reloadable="true" > par <?xml version="1.0" encoding="UTF-8"?> <Context docBase="DMIST" path="/DMIST" reloadable="true" >
Dans les deux cas, la connexion fonctionne si ce fichier est dans META-INF/context.xml
Dans les deux cas, la connexion ne fonctionne pas si ce fichier n'est pas dans META-INF/context.xml et mis manuellement dans conf/catalina/localhost/DMIST.xml

Je vous ai mis en PJ le serveur.xml et catalina.properties et .policy (catalina.conf n'existe pas).

A première vue, rien de différent à part les ports avec une installation classique