Bonne façon de faire DataSources / ressources un temps de réglage de déploiement

Question

J'ai une application web qui nécessite deux paramètres:

• Une source de données JDBC
• Un jeton de chaîne

Je veux désespérément être en mesure de déployer un .war à divers récipients différents (jetée, tomcat, minimum GF3) et configurer ces paramètres au niveau de l'application dans le conteneur.

Mon code fait ceci:

InitialContext ctx = new InitialContext();
Context envCtx = (javax.naming.Context) ctx.lookup("java:comp/env");
token = (String)envCtx.lookup("token");
ds = (DataSource)envCtx.lookup("jdbc/datasource")

Supposons que je l'ai utilisé l'interface de gestion GlassFish pour créer deux ressources jdbc: jdbc / test-DataSource et jdbc / live-DataSource qui se connectent à différentes copies du même schéma, sur des serveurs différents, différents titres de compétence etc. dire que je veulent déployer ce à glassFish et pointer à la source de données de test, je pourrais avoir dans mon soleil web.xml:

...
<resource-ref>
  <res-ref-name>jdbc/datasource</res-ref-name>
  <jndi-name>jdbc/test-datasource</jndi-name>
</resource-ref>
...

et

• sun-web.xml va dans ma guerre, non?
• il doit sûrement y avoir un moyen de le faire via l'interface de gestion

Suis-je même essayer de faire la bonne chose? Est-ce que d'autres conteneurs font plus facile? Je serais particulièrement intéressé par la façon dont la jetée 7 gère cela depuis que je l'utilise pour le développement.

EDIT Tomcat a une façon raisonnable de faire ceci:

Créer $TOMCAT_HOME/conf/Catalina/localhost/webapp.xml avec:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiResourceLocking="false" privileged="true">
  <!-- String resource -->
  <Environment name="token" value="value of token" type="java.lang.String" override="false" />

  <!-- Linking to a global resource -->
  <ResourceLink name="jdbc/datasource1" global="jdbc/test" type="javax.sql.DataSource" />

  <!-- Derby -->
  <Resource name="jdbc/datasource2"
    type="javax.sql.DataSource"
    auth="Container"
    driverClassName="org.apache.derby.jdbc.EmbeddedDataSource"
    url="jdbc:derby:test;create=true"
    />

  <!-- H2 -->
  <Resource name="jdbc/datasource3"
    type="javax.sql.DataSource"
    auth="Container"
    driverClassName="org.h2.jdbcx.JdbcDataSource"
    url="jdbc:h2:~/test"
    username="sa"
    password=""
    />
</Context>

Notez que override="false" signifie le contraire. Cela signifie que ce paramètre ne peut pas être outrepassée par web.xml.

J'aime cette approche parce que le fichier fait partie du conteneur configuration pas la guerre, mais il ne fait pas partie de la configuration globale; il est spécifique webapp.

Je suppose que j'attends un peu plus de GlassFish, car il est censé avoir une interface d'administration web complète, mais je serais assez heureux avec quelque chose d'équivalent à ce qui précède.

Answer 1

Pour GF v3, vous pouvez essayer de tirer parti de l'option --deploymentplan de la sous-commande deploy de asadmin. Il est discuté sur la pour la sous-deploy .

Answer 2

Nous avions juste cette question lors de la migration de Tomcat à GlassFish 3. Voici ce qui fonctionne pour nous.

• Dans la console d'administration Glassfish, configurer les sources de données (pools de connexion JDBC et ressources) pour DEV / TEST / PROD / etc.
• Enregistrez vos paramètres de temps de déploiement (dans notre base de données d'informations se connecter de cas) dans le fichier des propriétés. Par exemple:

# Database connection properties
dev=jdbc/dbdev
test=jdbc/dbtest
prod=jdbc/dbprod

• Chaque application Web peut charger le même fichier de propriétés de base de données.
• Lookup la ressource JDBC comme suit.

import java.sql.Connection;
import javax.sql.DataSource;
import java.sql.SQLException;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

/**
 * @param resourceName the resource name of the connection pool (eg jdbc/dbdev)
 * @return Connection a pooled connection from the data source 
 * associated with resourceName
 * @throws NamingException will be thrown if resource name is not found
 */
 public Connection getDatabaseConnection(String resourceName) 
             throws NamingException, SQLException {
    Context initContext = new InitialContext();
    DataSource pooledDataSource = (DataSource) initContext.lookup(resourceName);
    return pooledDataSource.getConnection();
 }

Notez que ceci est pas le processus en deux étapes habituelles impliquant un regard à l'aide du contexte de nommage « java: comp / env. » Je ne sais pas si cela fonctionne dans des conteneurs d'application autres que GF3, mais GF3 il n'y a pas besoin d'ajouter des descripteurs de ressources à web.xml lors de l'utilisation de l'approche ci-dessus.

Answer 3

Je ne suis pas sûr de comprendre vraiment la question / problème.

Fournisseur de composants d'application , vous déclarez la ressource (s) requise par votre application d'une manière standard (conteneur agnostique) dans le web.xml.

A l'heure du déploiement, le Application Deployer et administrateur est censé suivre les instructions fournies par le application fournisseur de composants pour résoudre les dépendances externes (entre autres), par exemple en créant une source de données au niveau du serveur d'applications et la cartographie de son vrai nom JNDI au nom de la ressource utilisée par l'application par l'utilisation d'un serveur d'application descripteur de déploiement spécifique (par exemple le sun-web.xml pour GlassFish). De toute évidence, c'est un spécifique conteneur étape et donc ne sont pas couverts par la spécification Java EE.

Maintenant, si vous voulez modifier la base de données d'une application utilise, vous devez soit:

• modifier le mappage dans le descripteur de déploiement du serveur d'applications - ou -
• modifier la configuration de la source de données existante pour en faire des points sur une autre base de données.

Avoir une interface d'administration ne change pas vraiment quoi que ce soit. Si je raté quelque chose, ne hésitez pas à me le faire savoir. Et juste au cas où, peut-être avoir un regard sur cette réponse précédente .