Affichage des articles dont le libellé est configuration. Afficher tous les articles
Affichage des articles dont le libellé est configuration. Afficher tous les articles

mardi 24 mai 2016

Externaliser la configuration d'une webapp


Comment permettre à une application web Java de récupérer un paramètre de configuration sans avoir à repackager le ".war" ?



Si on s'interdit de modifier le fichier ".war" ça veut dire que l'on ne peut plus utiliser les possibilités de configuration à partir des fichiers qu'il contient ( web.xml, fichiers properties, etc ).
Les paramètres de configuration devront donc être portés par les environnements d'exécution de l'application (et non par l'application elle même), c'est à dire le server d'applications ( Tomcat, Jetty, etc ) ou le système d'exploitation.
Les trois possibilités les plus courantes sont décrites ci-après...

1) Utiliser une variable d'environnement

- Définir la variable d'environnement au niveau du système d'exploitation
Exemple sous Linux  :
   export MYFOLDER=/tmp/foo

- Récupérer la valeur de cette variable dans le code Java,
  par exemple dans une classe de type  "ServletContextListener" :
    String value = System.getenv("MYFOLDER")

Cette solution est simple et applicable indépendamment type de serveur d'applications.
Mais elle nécessite une intervention au niveau "système d'exploitation" (pas toujours possible) et on ne peut avoir qu'une seule valeur pour toutes les instances de serveurs d'application sur un même OS.


2) Configurer une propriété de type "Java System property"

Il s'agit de définir une propriété pour la JVM au lancement du serveur d'applications.

- Définir la propriété pour un serveur d'applications particulier :
Soit avec l'option "-D" de la ligne de commande
Soit en utilisant les fichiers de configuration propres à chaque serveur d'application
Exemple pour Tomcat :
        Dans le fichier "catalina.properties" de Tomcat :
    myfolder=/tmp/foo
       
        NB : pour un lancement dans Eclipse utiliser le fichier "catalina.properties"
                 situé dans le workspace (dans  "Servers" )

- Récupérer la valeur de cette propriété dans le code Java :
    String value = System.getProperty("myfolder");


3) Configurer une "valeur nommée" accessible via JNDI

Une "ressource nommée" peut être définie au niveau du serveur d'applications, elle sera ensuite récupérée via JNDI.

- Définir la "ressource nommée" pour le serveur d'applications concerné

Pour Tomcat :
        Dans le fichier "web.xml" de Tomcat (fichier global pour toutes les webapps) :
      <env-entry>
          <env-entry-name>myTextValue</env-entry-name>
          <env-entry-type>java.lang.String</env-entry-type>
          <env-entry-value>foo</env-entry-value>
      </env-entry>
      <env-entry>
          <env-entry-name>myMaxValue</env-entry-name>
          <env-entry-type>java.lang.Integer</env-entry-type>
          <env-entry-value>10</env-entry-value>
      </env-entry>
        NB :
        - respecter l'ordre des tags "name/type/value"
        - pour un lancement dans Eclipse utiliser le fichier "web.xml" situé
          dans le workspace (dans  "Servers" )
       
        cf https://tomcat.apache.org/tomcat-7.0-doc/config/globalresources.html#Environment_Entries 

Pour Jetty :
        Dans le fichier "jetty.xml" ajouter une ressource avec une entrée du type :
     <New class="org.eclipse.jetty.plus.jndi.EnvEntry">
       <Arg></Arg> <!-- scope : empty = JVM scope-->
       <Arg>myTextValue</Arg> <!-- name -->
       <Arg type="java.lang.String">foo</Arg> <!-- value-->
       <Arg type="boolean">true</Arg>  
     </New>

        cf http://www.eclipse.org/jetty/documentation/current/using-jetty-jndi.html

- Récupérer la valeur de cette variable dans le code Java
  Exemple pour une chaine de caractères :

   String name = "myTextValue" ;
   try {
      Object value = InitialContext.doLookup("java:comp/env/"+name);
      System.out.println("JNDI OBJECT '"+ name + "' = '" + value + "'");
   } catch (NamingException e) {
      System.out.println("JNDI OBJECT ERROR : " + e.getMessage());
      e.printStackTrace();
   }


mardi 9 avril 2013

Créer un launch Maven sous Eclipse avec le plugin m2e


Quand on utilise Maven en ligne de commande il est facile d’automatiser le lancement d’une tâche en créant un fichier de commande .sh ou .bat qui définira la configuration de la commande à lancer.
Exemple : mvn sonar:sonar sans les test, en mode debug , etc…

Mais dans Eclipse, qu’en est-il ?

De base le plugin « m2e » propose les lancements usuels de Maven ( build, clean, install, etc ) :


Ce qui permet de réaliser les opérations de base, mais elles se révèlent vite insuffisantes.

Puisqu’Eclipse utilise "Run as..." pour lancer Maven, il suffit de définir une nouvelle configuration pour pouvoir ensuite la lancer.

Remarque : "Run as..." est systématiquement disponible, pour tous les types de projets Eclipse, même pour un projet de type "General". Les configurations proposées varient en fonction du type de projet, mais on dispose toujours au moins de "Run Configurations…" qui donne accès aux différentes configurations définies dans le workspace.




1 - Définir une nouvelle configuration de lancement 


Il suffit donc de passer par "Run As / Run Configurations" pour obtenir la fenêtre suivante :



On y trouve toutes les configurations de lancement déjà définies, dont celles de Maven

Pour créer une configuration Maven :

  • Sélectionner "Maven Build"
  • Cliquer sur l’icône "New" pour créer une nouvelle configuration



Dans l’onglet "Main" indiquer

  • le nom de la configuration
  • le répertoire de base, utiliser une variable Eclipse plutôt qu’un chemin dans le filesystem ou dans le workspace,  ${project_loc} est la variable la mieux adaptée puisqu’elle contient le path absolu du projet sélectionné
  • le goal (ou les goals), par exemple "sonar:sonar", "clean install", etc…



Dans l’onglet "JRE" il est important de sélectionner le JRE qui va servir à l’exécution de Maven et notamment à compiler les sources (il faut donc référencer un JDK complet incluant tools.jar qui contient le compilateur Java )
Pour être cohérent, ce JRE doit être le même que celui du projet Java dans Eclipse



Enregistrer la configuration avec "Apply"

Pour lancer la configuration, utiliser "Run As – Run Configuration", sélectionner la configuration qui vient d’être créée, puis "Run".


2 - Enregistrer une configuration de lancement dans un fichier


Créer une configuration spécifique c’est très bien, mais si on pouvait la conserver dans un fichier, lui-même enregistré dans le projet concerné, ça permettrait de recopier ce fichier en cas de besoin, de le stocker avec les sources dans SVN ou GIT, etc…

Pour ce faire :
  • Ouvrir les configurations ( "Run As – Run Configuration" )
  • Sélectionner la configuration à enregistrer
  • Dans l’onglet "Commons" : 
    • remplacer "Save as – Local file" par "Save as – Shared file", 
    • utiliser "Browse" pour sélectionner le projet 
    • le nom du fichier sera le nom de la configuration avec l’extension ".launch"


Utiliser "Apply" pour enregistrer dans le fichier
Le fichier  "nom_de_configuration.launch"  apparaît dans le projet
Si on l’ouvre par un "double-click" on constate qu’il s’agit d’un simple fichier XML.

Pour lancer la configuration à partir du fichier, il suffit de faire un "click-droit" + "Run As" et Eclipse propose immédiatement la configuration sélectionnée dans le menu contextuel.
Elle peut donc maintenant être lancée directement par le fichier.

Si le fichier ne contient aucune information spécifiquement liée au projet (chemin absolu, JRE particulier, etc) il pourra être copié d’un projet à autre, et réutilisé à volonté.

---
Tutoriel rédigé grâce aux conseils avisés de Stéphane (http://techasite.blogspot.fr/)

mercredi 6 février 2013

Configuration de Subversion pour Eclipse avec Subclipse

"Subclipse" ( le plugin Eclipse pour Subversion ) est un classique.
Cependant, son utilisation avec un proxy peut poser quelques problèmes.
Il n'est pas rare d'être confronté à l'erreur suivante :
RA layer request failed svn: OPTIONS of ... 
quand la connexion change (avec proxy, sans proxy, changement de proxy, etc... )

Le premier réflexe est d'aller voir la configuration du proxy dans Eclipse, mais rien n'y fait.
L'explication est que si on utilise l'interface JavaHL JNI (cf "Window/Preferences/Team/SVN - SVN interface" ) c'est la configuration native de Subversion (au niveau du système d'exploitation) qui est utilisée. 

Il faut donc descendre d'un niveau et aller vérifier la configuration de la couche cliente de Subversion dans les  fichiers du système.

Sous Windows, à l'emplacement de la configuration de l'utilisateur se trouve un répertoire "Subversion"
( quelque chose du genre "C:\Documents and Settings\(USERNAME)\Application Data\Subversion"
ou "(USERS)\(USERNAME)\AppData\Roaming\Subversion" sous Windows 7 )

Dans ce répertoire, on trouve les fichiers "config" et "servers" :
. "config" sert à configurer le comportement "côté-client"
. "servers" sert à configurer les paramètres de connexion au serveur et notamment le proxy

Il suffit donc d'éditer le fichier "server" avec un éditeur de texte et de vérifier la configuration du proxy :
  • http-proxy-host = le.serveur.proxy
  • http-proxy-port = le.port.du.serveur.proxy
  • (et les autres paramètres du proxy si nécessaire )

Quand cette configuration est correcte, l'utilisation de Subclipse ne pose plus de problème, même en supprimant la configuration du proxy dans Eclipse !

Une autre méthode consiste à utiliser TortoiseSVN http://tortoisesvn.net/ ) pour gérer la configuration native de Subversion ( "Settings/Network" ) ce qui permet également de tester la connexion indépendamment d'Eclipse.

Voir aussi  http://java-espresso.blogspot.fr/2011/09/orgtigrissubversionjavahlclientexceptio.html