modo corretto di fare datasources / risorse di regolazione deploy-tempo

Question

Ho un web-app che richiede due impostazioni:

• Un JDBC origine dati
• Un token di stringa

ho disperatamente voglio essere in grado di implementare un .war di vari contenitori diversi (pontile, Tomcat, minimo GF3) e configurare queste impostazioni a livello di applicazione all'interno del contenitore.

Il mio codice fa questo:

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")

Supponiamo che ho usato l'interfaccia di gestione pesci vetro per creare due risorse JDBC: jdbc / test-DataSource e JDBC / live-origine dati che si collegano a diverse copie dello stesso schema, su server diversi, diverse le credenziali ecc Say I desidera distribuire questo per Glassfish con e puntarlo verso l'origine dati di test, potrei avere questo nel mio sun-web.xml:

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

ma

• sun-web.xml va all'interno la mia guerra, vero?
• Sicuramente ci deve essere un modo per fare questo attraverso l'interfaccia di gestione

Sto ancora cercando di fare la cosa giusta? Do altri contenitori rendono questo più facile? Sarei particolarmente interessato a come molo 7 gestisce questo dato lo uso per lo sviluppo.

Modifica Tomcat ha un modo ragionevole per fare questo:

Crea $TOMCAT_HOME/conf/Catalina/localhost/webapp.xml con:

<?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>

Si noti che override="false" significa il contrario. Ciò significa che questa impostazione non può essere sovrascritto di web.xml.

Mi piace questo approccio perché il file è parte del contenitore di configurazione non la guerra, ma non è parte della configurazione globale; è specifica webapp.

Credo che mi aspetto un po 'più da pesci vetro in quanto si suppone di avere una completa interfaccia di amministrazione via web, ma sarei abbastanza felice con qualcosa di equivalente a quanto sopra.

Answer 1

Per GF v3, si consiglia di provare sfruttando l'opzione --deploymentplan del sottocomando deploy di asadmin. Si è discusso sulla per Distribuisci sottocomando .

Answer 2

Abbiamo avuto solo questo problema durante la migrazione da Tomcat a GlassFish 3. Qui è ciò che funziona per noi.

• Nella console di amministrazione Glassfish, configurare origini dati (pool di connessioni JDBC e risorse) per DEV / TEST / CODICE / etc.
• Registra i tuoi parametri di tempo di implementazione (nel nostro database caso informazioni collegarsi) in file di proprietà. Ad esempio:

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

• Ogni applicazione web può caricare lo stesso file proprietà del database.
• Lookup la risorsa JDBC come segue.

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();
 }

Si noti che questo è non il consueto processo in due fasi che coinvolge uno sguardo utilizzando il contesto di denominazione "java:. Comp / env" Non ho idea se questo funziona in contenitori di applicazioni diverse da GF3, ma in GF3 non c'è bisogno di aggiungere descrittori di risorse per web.xml quando si utilizza l'approccio di cui sopra.

Answer 3

Non sono sicuro di capire realmente la questione / problema.

Come Component Application Provider , si dichiara la risorsa (s) richiesto dalla vostra applicazione in un modo standard (contenitore agnostica) nella web.xml.

in fase di distribuzione, il Applicazione Deployer e amministratore dovrebbe seguire le istruzioni fornite dal Application Provider Componente per risolvere le dipendenze esterne (tra le altre cose), ad esempio con la creazione di un dataSource a livello di server di applicazione e mappare il suo vero nome JNDI per il nome della risorsa utilizzata dall'applicazione attraverso l'uso di un descrittore di distribuzione specifica application server (ad esempio, il sun-web.xml per GlassFish). Ovviamente, questa è una contenitore specifico passo e quindi non coperti dalla specifica Java EE.

Ora, se si desidera modificare il database viene utilizzata da un'applicazione, si dovrà o:

• cambiare la mappatura nel descrittore di distribuzione application server - oppure -
• modificare la configurazione del datasource esistente per renderlo punti su un altro database.

Avere un'interfaccia di amministrazione in realtà non cambia nulla. Se ho perso qualcosa, non esitate a farmi sapere. E solo nel caso in cui, forse dare un'occhiata a questa risposta precedente .