Off the record

Aller au contenu | Aller au menu | Aller à la recherche

jeudi 6 décembre 2007

Forward de ports...

Bon. On a besoin de tester un produit dont la license est limitée à l'usage sur l'hôte localhost? Bon. Une petite manip simple peut nous aider à le tester quand même sur des hôtes distants.
Il suffit en fait d'ouvrir un port d'écoute localement (comme le fait tout serveur) par exemple le port XXX. Bon. On lie ensuite ce port via une connection distante sur le protocole ssh à la machine distante. Et le tour est joué. Le navigateur demande l'url localhost port XXX : http://localhost:XXX et le système d'exploitation sait qu'il faut alors faire suivrela demande à la machine distante via la connection ssh préalablement ouverte...
Mais ça le browser n'en a pas connaissance. Il croit que le serveur contacté est bien local. Magie.

Donc la commande magique pour ouvrir le port local vers le port distant via ssh :
ssh –L local_port: remote_machine_name:remote_port login@remote_machine_name

Enjoy.

mercredi 5 décembre 2007

Paradigmes objet et relationel

Paradigme : Un paradigme est une représentation du monde, une manière de voir les choses [...] wikipedia.
La suite? ->

Lire la suite

mardi 4 décembre 2007

Tomcat, JNDI et resources factories.

Configuration(s) de JNDI

Tomcat offre un service de nommage JNDI, par webapp depuis la version 5.5. Comment le configurer et y accéder?
Il faut, si l'on veut insérer une information dans le context général, commun à toutes les applications tournant sur le serveur, ajouter les lignes suivantes dans $TOMCAT_HOME/conf/context.xml : (exmple pour une datasource)

  <Resource name="jdbc/TestDB" auth="Container" type="javax.sql.DataSource"
        username="sa"
        password=""
        driverClassName="org.hsqldb.jdbcDriver"
        url="jdbc:hsqldb:hsql://localhost/data"/>

Si l'on veut restreindre l'acessibilité du contexte à une application web, il suffit de créer un fichier context.xml contenant les lignes ci-dessus (dans un tag <context></context>) dans le répertoire META-INF de la webapp et de déployer sous forme d'archive web (war).

On accédera ensuite à l'objet avec un code de type

Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");

if (envCtx == null)
   throw new Exception("Boom - No Context");
 
   DataSource ds = (DataSource) envCtx.lookup("jdbc/TestDB");
   if (ds != null) {
      Connection conn = ds.getConnection();
      // etc etc...

A noter que le registre JNDI de Tomcat est readonly, il n'est donc pas modifiable par programmation. On ne peut le configurer qu'au démarrage du serveur ou lors du déploiement d'une application...

Les "resources factories" proposées par Tomcat

Donc non seulement le service JNDI de Tomcat nous a permis de référencer une source de données, nous permettant ainsi de nous affranchir d'un nommage (et d'un paramétrage) dans l'application elle même, mais en plus, comme on le voit dans le code ci-dessus, Tomcat nous simplifie encore une étape en construisant pour nous l'objet Java Datasource directement, sur la base des infos JNDI.
Tomcat dispose en effet de "ressources factories", dans le cas ci-dessus, nous avons utilisé la "datasource factory". Ok quelles sont les autres?
De base, Tomcat fournit les factories suivante :

  • JDBC datasource factory
  • Javamail session factory
  • Javabean factory (similaire à Spring, en un sens)

On peut ensuite intégrer sa propre factory d'objet à Tomcat si l'on en ressent le besoin, une custom factory en fait...
Plus ici.

lundi 3 décembre 2007

Générer un fichier war avec Ant

De manière automatisée, il suffit de dire à Ant ou est le descripteur de déploiement web.xml, les classes Java et le tour est joué :

<target name="war" depends="compile">
   <war destfile="hibernate-tutorial.war" webxml="web.xml">
       <lib dir="${librarydir}">
         <exclude name="jsdk*.jar"/>
       </lib>
       <classes dir="${targetdir}"/>
   </war>
</target>