J'aime .properties fichiers au lieu de
- JNDI - pourquoi construire un objet complexe lors de la configuration du programme au lieu du temps d'initialisation ?
- propriétés système - vous ne pouvez pas configurer séparément plusieurs instances du même WAR dans un seul Tomcat
- paramètres de contexte - ils sont accessibles uniquement en
javax.servlet.Filter,javax.servlet.ServletContextListenerce qui peut être gênant
Tomcat 7 Context contient l'élément Loader. Selon le descripteur de déploiement de la documentation (ce qui est dans <Context> tag) peut être placé dans :
$CATALINA_BASE/conf/server.xml- mauvais - nécessite le redémarrage du serveur pour relire la configuration$CATALINA_BASE/conf/context.xml- mauvais - partagé entre toutes les applications$CATALINA_BASE/work/$APP.war:/META-INF/context.xml- mauvais - nécessite un reconditionnement afin de modifier la configuration$CATALINA_BASE/work/[enginename]/[hostname]/$APP/META-INF/context.xml- gentil , mais voir la dernière option !!$CATALINA_BASE/webapps/$APP/META-INF/context.xml- gentil , mais voir la dernière option !!$CATALINA_BASE/conf/[enginename]/[hostname]/$APP.xml- meilleur - complètement hors application et automatiquement scanné pour les changements !!!
Context peut contenir Loader personnalisé org.apache.catalina.loader.VirtualWebappLoader (disponible dans Tomcat 7 moderne, vous pouvez ajouter propre classpath séparé à votre .properties ), et Parameter (accessible via FilterConfig.getServletContext().getInitParameter(name) ) et Environment (accessible via new InitialContext().lookup("java:comp/env").lookup("name") ):
<Context docBase="${basedir}/src/main/webapp"
reloadable="true">
<!-- http://tomcat.apache.org/tomcat-7.0-doc/config/context.html -->
<Resources className="org.apache.naming.resources.VirtualDirContext"
extraResourcePaths="/WEB-INF/classes=${basedir}/target/classes,/WEB-INF/lib=${basedir}/target/${project.build.finalName}/WEB-INF/lib"/>
<Loader className="org.apache.catalina.loader.VirtualWebappLoader"
virtualClasspath="${basedir}/target/classes;${basedir}/target/${project.build.finalName}/WEB-INF/lib"/>
<JarScanner scanAllDirectories="true"/>
<Parameter name="min" value="dev"/>
<Environment name="app.devel.ldap" value="USER" type="java.lang.String" override="true"/>
<Environment name="app.devel.permitAll" value="true" type="java.lang.String" override="true"/>
</Context>
Si vous utilisez Spring et sa configuration XML :
<context:property-placeholder location="classpath:app.properties"/>
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="oracle.jdbc.OracleDriver"/>
<property name="url" value="jdbc:oracle:thin:@${db.host}:${db.port}:${db.user}"/>
<property name="username" value="${db.user}"/>
<property name="password" value="${db.pass}"/>
</bean>
Avec Spring, il est facile d'injecter les propriétés ci-dessus dans les champs de haricots :
@Value("${db.user}") String defaultSchema;
au lieu de JNDI :
@Inject ApplicationContext context;
Enviroment env = context.getEnvironment();
String defaultSchema = env.getProperty("db.user");
Notez également que EL autorise ceci (valeurs par défaut et substitution récursive profonde) :
@Value('${db.user:testdb}') private String dbUserName;
<property name='username' value='${db.user.${env}}'/>
Voir aussi :
- Ajout d'un répertoire au chemin de classe tomcat
- Puis-je créer un chemin de classe personnalisé pour chaque application dans Tomcat ?
- Comment lire un fichier de propriétés en dehors de mon contexte d'application Web dans Tomcat
- Configurer Tomcat pour utiliser le fichier de propriétés pour charger les informations de connexion à la base de données
- Devez-vous configurer les propriétés de connexion à la base de données dans server.xml ou context.xml
- Externaliser la configuration de Tomcat
REMARQUE Avec l'extension du chemin de classe au répertoire en direct, vous avez également autorisé à externiliser toutes les autres configurations , comme la journalisation, auth, atc. J'externalise logback.xml de telle manière.
MISE À JOUR Tomcat 8 modifie la syntaxe pour <Resources> et <Loader> éléments, la partie correspondante ressemble maintenant à :
<Resources>
<PostResources className="org.apache.catalina.webresources.DirResourceSet"
webAppMount="/WEB-INF/classes" base="${basedir}/target/classes" />
<PostResources className="org.apache.catalina.webresources.DirResourceSet"
webAppMount="/WEB-INF/lib" base="${basedir}/target/${project.build.finalName}/WEB-INF/lib" />
</Resources>
Votre tomcat/conf/Catalina/<host> peut contenir des descripteurs de contexte qui vous permettent de configurer de nombreuses choses, y compris la définition des "entrées d'environnement", qui sont accessibles depuis Java via JNDI. Il existe de nombreuses façons de l'utiliser. Personnellement, j'ai défini une entrée d'environnement qui est le chemin du système de fichiers vers mon fichier de propriétés. Mon application est conçue pour vérifier cette entrée, et si elle n'existe pas, recherchez plutôt le fichier sur le chemin de classe. De cette façon, dans dev, nous avons les propriétés dev directement sur le chemin de classe, mais lorsque nous construisons et déployons, nous le pointons vers un fichier externe.
Il existe une bonne documentation pour configurer un contexte sur le site Web de Tomcat. Voir Définir un contexte section sur les détails de la façon de créer le fichier et où le mettre.
Par exemple, si votre hébergeur s'appelle myHost et votre application est un fichier war nommé myApp.war dans le webapps répertoire, alors vous pourriez créer tomcat/conf/Catalina/myHost/myApp.xml avec ce contenu :
<Context>
<Environment name="configurationPath" value="/home/tomcat/myApp.properties" type="java.lang.String"/>
</Context>
Ensuite, à partir de votre code, vous feriez une recherche JNDI sur java:comp/env/configurationPath (95 % de certitude ici) pour obtenir cette valeur de chaîne.
Vous pouvez essayer de placer votre configuration (fichier de propriétés) dans Apache Tomcat\lib dans le fichier JAR et le supprimer de l'application Web. Lorsque le chargeur de classe de Tomcat ne trouvera pas votre configuration dans l'application Web, il essaiera de la trouver dans le répertoire "lib". Ainsi, vous pouvez externaliser votre configuration en déplaçant simplement la configuration vers le répertoire global lib (elle est partagée entre d'autres applications Web).