Guillaume VIEL :: blog Openfarm :: java jee tomcat linux

L'interface d'administration de proxmox permet de créer, détruire, modifier, migrer une VM. Mais l'interface ne permet pas de cloner la VM. Voici comment j'ai procédé :

Au secours! Lorsque Flex vous met un joli message RSL error 1 of 1 c'est que vous avez tout simplement oublié de lui indiquer une librairie Flex (librairie SWC ou SWZ).

Dans mon cas c'est la librairie RPC (il y a en trois essentiel framework, rpc et datavizualisation).

Ensuite tout va beaucoup mieux!

Sources :

http://livedocs.adobe.com/flex/3/html/help.html?content=rsl_09.html

Je déploie habituellement les applications web dans Tomcat en multi-instance avec une instance Tomcat par application (ceux qui croient que c'est une hérésie iront voir les concepteurs de Tomcat Mark Thomas et Filip Hanik qui préconisent eux mêmes cette solution). Cependant, dans certains contextes, et notamment chez certains clients, les contraintes font que l'on est obligé de faire autrement...

Dans le cas présent, c'est la configuration de log4j via Spring qui pose (encore) problème : je déploie 2 applications identiques (avec configuration applicative légèrement différente) sous 2 contextes différents dans le même serveur Tomcat. Se posent donc 2 problèmes :

• il faut pouvoir packager l'application sous des formes différentes et notamment 2 contextes différents : /my-app1 et /my-app2, donc paramétrer le packaging
• la configuration log4j est à priori identique pour ces 2 applications (packages identiques) : ceci pose le problème de la séparation des logs (et éventuellement la différenciation des niveaux de log)

Lorsqu'on doit inclure du code HTML généré dans une page freemarker (sous la forme d'une chaîne), il faut utiliser cette syntaxe pour que les tags HTML ne soient pas "échappés" :

${StringUtil.wrapString( htmlString ? if_exists ) }

htmlString étant une chaine qui aura par exemple été mis dans le contexte via un script grovvy ou un service.

Dans les scripts shell, il est toujours utile de savoir manipuler correctement les commandes courantes de compression comme bzip2, gzip et tar, et notamment leurs interactions possibles avec l'entrée standard (stdin) et la sortie standard (stdout). L'avantage d'utiliser cette méthode est qu'elle est compatible avec tous les systèmes *NIX !

Créer des archives

On utilise l'option c(reate) de tar dont le résultat est envoyé dans un pipe vers gzip ou bzip2. La redirection > permet d'envoyer le résultat final dans un fichier :

   tar cv file1 [file2] ... | gzip > archname.tar.gz
   tar cv file1 [file2] ... | bzip2 > archname.tar.bz2

Décompacter des archives

   gzip -cd archname.tar.gz | tar xv
   bzip2 -cd archname.tar.bz2 | tar xv

Lire le contenu d'une acrhive

   gzip -cd archname.tar.gz | tar tv
   bzip2 -cd archname.tar.bz2 | tar tv

NOTA BENE

Le programme tar peut parfois pointer par défaut sur un device prédéfini (comme un magnéto à bande) si l'option f n'est pas précisée. Sur certains systèmes il faut donc préciser f - pour forcer tar à orienter vers l'entrée / sortie standard. Exemple :

tar cvf - file1 [file2] ... | gzip > archname.tar.gz

Sur une application destinée à l'international, j'ai tout naturellement souhaité introduire l'internationalisation (i18n) des messages destinés aux utilisateurs, aux logs, aux erreurs etc.

Je me suis penché sur ce que propose Spring et j'ai commencé avec cette configuration très sommaire :

<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
    <property name="basename" value="message"/>
</bean>

Le premier problème c'est l'apparition de ??? à la place de certains caractères UTF-8 : gênant non?! Ceci est en fait dû au ResourceBundleMessageSource de Spring qui utilise les classes standards java.util.ResourceBundle et java.util.Properties, or ces dernières ne supportent visiblement que l'encodage ISO-8859-1 !!!

La solution est d'utiliser le ReloadableResourceBundleMessageSource de Spring, plus complet. Il suffit de lui indiquer le defaultEncoding choisi.

L'autre problème est la non reconnaissance des fichiers de properties (mis dans le classpath) que j'ai nommés message_en.properties , message_fr.properties, etc. Apparemment il faut ajouter le paramètre fallbackToSystemLocale=false sur le ReloadableResourceBundleMessageSource de Spring pour éviter que soient recherchés les fichiers du type message_fr_FR ou message_en_FR.

<bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
    <property name="basename" value="classpath:message"/>
    <property name="fallbackToSystemLocale" value="false" />
    <property name="defaultEncoding" value="UTF-8"/>
</bean>

Sources :

http://www.cakesolutions.net/teamblogs/2009/04/02/utf-8-encoding-and-message-sources/

http://forum.springsource.org/showthread.php?t=18199&page=2

Lors d'un test de l'archetype plugin de maven, j'obtenais un build failure avec un Required goal not found alors que tout fonctionnait auparavant...

Voici le contenu du .m2\repository\org\apache\maven\plugins\maven-archetype-plugin\maven-metadata-central.xml

<?xml version="1.0"?><metadata>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-archetype-plugin</artifactId>
  <versioning>
    <latest>1.0-alpha-4</latest>
    <release>1.0-alpha-4</release>
    <versions>
      <version>1.0-alpha-3</version>
      <version>1.0-alpha-4</version>
    </versions>
    <lastUpdated>20060507072802</lastUpdated>
  </versioning>
</metadata>

En fait, il faut le corriger comme ceci pour que tout fonctionne correctement (en téléchargeant directement sur un repository en ligne le fichier maven-metadata.xml)

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-archetype-plugin</artifactId>
  <versioning>
    <latest>2.0</latest>
    <release>2.0</release>
    <versions>
      <version>1.0-alpha-3</version>
      <version>1.0-alpha-4</version>
      <version>1.0-alpha-7</version>
      <version>2.0-alpha-1</version>
      <version>2.0-alpha-2</version>
      <version>2.0-alpha-3</version>
      <version>2.0-alpha-4</version>
      <version>2.0-alpha-5</version>
      <version>2.0</version>
    </versions>
    <lastUpdated>20101028011818</lastUpdated>
  </versioning>
</metadata>

Et voilà!

Pour connaitre le temps d'activité d'un serveur depuis son dernier démarrage, sous Linux, c'est la commande uptime :

# uptime
 10:38:26 up 153 days, 19:49,  1 user,  load average: 1.18, 0.76, 0.46

Par contre sous windows, c'est un peu plus compliqué, et les calculs sont à faire par vos soins (où alors je n'ai pas trouvé la commande!)... Je n'ai trouvé que ça :

>net statistics serveur
Statistiques de serveur de \\MYSERVER


Statistiques depuis 10/13/2010 10:07 AM


Sessions acceptées                             1
Déconnexions automatiques                      0
Déconnexions sur erreur                        6

Kilo-octets envoyés                            8
Kilo-octets reçus                              11

Temps de réponse moyen (ms)                    0

Erreurs système                                0
Violations d'autorisation                      12
Violations de mot de passe                     0

Fichiers utilisés                              0
Périphériques comm. utilisés                   0
Travaux d'impression mis en file d'attente     0

Saturation des zones tampon

  de grande taille                             0
  de demande                                   0

La commande s'est terminée correctement.

Bien d'Hibernate soit capable d'aller chercher des données dans des tables situées dans différents schémas, il n'est pas possible directement de changer le schéma à l'exécution. En effet, les annotations sont lues à  la compilation et le code d'une @Entity est alors figé sur un schéma et une table.

@Entity
@Table(name="MON_OBJET",schema="MON_SCHEMA")
public class MonObjet implements Serializable {
...
   private Etat etat;
...
   @OneToOne(...)
   public Etat getEtat() { ... }
   public void setEtat(Etat etat) { ... }
}

@Entity
@Table(name="ETAT",schema="MON_SCHEMA")
public class Etat {
...
}

Ceci devient gênant lorsque par exemple, une des entités peut se trouver dans différents schémas qui correspondent par exemple à des environnements différents. Par exemple, si MonObject est attaché en relation un à un à un objet Etat qui peut se trouver dans MON_SCHEMA, SCHEMA_PREPROD ou SCHEMA_PROD, on devra alors packager une application par schéma!

Une solution possible serait de créer un profile maven pour chaque environnement, puis d'utiliser la phase de génération des sources pour modifier les annotations dans le code java... Ce qui semble plutôt lourd à mettre en place! Et au final, il faut toujours une application par schéma utilisé! Il existe cependant une solution avec les interceptor d'Hibernate pour ne déployer qu'une seule application...

La configuration d'un proxy sous maven est a priori simple : il suffit d'ajouter la section suivante dans le fichier ~/.m2/settings.xml :

<proxies>
<proxy>
<active>true</active>
<protocol>http</protocol>
<host>proxy.somewhere.com</host>
<port>8080</port>
<username>proxyuser</username>
<password>somepassword</password>
<nonProxyHosts>localhost|10.*</nonProxyHosts>
</proxy>
</proxies>

Mais pour le protocole HTTPS la documentation n'indique rien! Si l'on essaye de transposer et d'ajouter un proxy avec
<protocol>https</protocol>
cela ne marche pas beaucoup plus...
La solution consiste à ajouter ceci à la variable d'environnement MAVEN_OPTS :

MAVEN_OPTS=$MAVEN_OPTS -Dhttps.proxyHost=proxy.somewhere.com -Dhttps.proxyPort=8080

La puissance de Spring AOP se limite a priori à son contexte (cf ce post http://forum.springsource.org/archive/index.php/t-11673.html )... Les servlets sont hors contexte Spring car gérées par le serveur d'application JEE et semblent exclues du champ de Spring AOP. Cependant, il est tentant de vouloir quand même utiliser Spring AOP sur les servlets sans avoir à passer par d'autres tisseurs d'aspects (comme AspectJ) qui complexifient la configuration du serveur d'application et le déploiement de l'application. Il s'avère que c'est possible par un moyen détourné. Il fallait juste y penser.

Cette exception peut se produire lorsque votre webservice contient des objets complexes (objets imbriqués) qui ne sont pas forcément visible dans votre déclaration de service. Pour qu'ils soient pris en compte, la solution est d'utiliser l'annotation @XmlSeeAlso(MyObjectFactory.class, MyOtherObjectFactory.class) sur votre webservice JAX-WS en lui indiquant les fabriques d'objets souhaitées. JAX-B pourra alors fabriquer tous les objets nécessaire au fonctionnement du webservice.

Source : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6419632

Il est parfois utile de comprendre ce que fait le driver JDBC Oracle que les développeurs connaissent sous le nom de ojdbc14.jar. Il existe en fait un autre driver destiné au debug : ojdbc14_g.jar pour lequel il suffit d'ajouter ceci dans les JAVA_OPTS pour activer les traces

JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.config.file=OracleLog.properties -Doracle.jdbc.Trace=true"

Ensuite, un fichier OracleLog.properties doit être placé avec le jar pour configurer les traces souhaitées. Il est conseillé de le modifier sinon vous allez avoir beaucoup de traces...

Ils l'ont fait!

Deux architectes java d'Openfarm sont désormais certifiés Scrum Master :

• Guillaume VIEL
• Eric MICHEL

L'explication de Scrum est ici pour ceux qui ne connaissent pas

Optimiser le temps de déploiement devient parfois crucial pour éviter de perdre des heures... Après avoir tenté des plugins maven (comme cargo par exemple) sans être totalement convaincu par leur efficacité (quand ça marche!), il m'a semblé plus efficace de recourir au script shell.

Maven est idéal pour toutes ces tâches mais nécessite parfois un peu de tuning, notamment lorsqu'on lui demande le packaging de l'application avec le plugin maven-war-plugin. L'opération est laborieuse et nécessite ensuite le déploiement d'un WAR ce qui veut dire que (de façon raccourcie car maven fait plus de choses en réalité) :

• maven compile l'application
• Maven copie les classes compilées et les fichiers de ressource dans une structure éclaté (dans le répertoire target)
• Maven zippe le tout dans un WAR (et c'est long!)
• ensuite il faut uploader le WAR vers le serveur cible
• Tomcat ou votre serveur d'application java doit ensuite dézipper l'archive...

L'utilisation d'API Oracle Java, comme par exemple la SDO API (sdoapi.jar) ou Oracle Network Modeling (sdonm.jar) pour gérer les graphes, nécessite d'avoir une connexion native Oracle. Or les applications sont souvent configurées avec un pool de connexions gérées par le conteneur JEE. Ceci pose alors problème pour les opérations spécifiques qui nécessitent d'avoir une connexion de type oracle.jdbc.OracleConnection et non une connexion de type java.sql.Connection. Cette dernière ne pourra en effet pas être utilisée avec les méthodes des API Oracle en Java.

Il faut alors extraire la connexion native sous-jacente à la connexion du pool de connexions.

Lors de la réinstallation de FreeNAS 0.69.2 (downgrade depuis la version 0.7.1) sur carte flash j'obtiens ça :

Cannot dump. No dump device defined.
Automatic reboot in 15 seconds - press a key on the console to abort

Beuh... En fait il s'avère qu'il faille démarrer en mode no ACPI sur le premier menu de démarrage. Le problème est : comment automatiser le démarrage pour que ce soit toujours l'option 2 du boot qui soit prise en compte?

Nous utilisons rsnapshot pour réaliser nos sauvegardes. En le résinstallant sur une machine je remarque sur le log de sauvegarde le message suivant :

La documentation Oracle FCF (Fast Connection Failover) pour configurer un pool de connexion JDBC avec un cluster Oracle RAC 10g est plutôt obscure et manque d'exemple...

Après quelques tâtonnements et en fouillant un peu, voici une configuration sous Tomcat à mettre dans le context.xml de l'application web ou dans server.xml (déconseillé sauf en ressource globale) qui semble plaire à Oracle :

    <Resource name="jdbc/myRacDb" auth="Container"
            type="oracle.jdbc.pool.OracleDataSource"
            factory="oracle.jdbc.pool.OracleDataSourceFactory"
            description="My Oracle RAC DB"
            user="myschema" password="mypass"
            url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=rac1.mydomain.com)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=rac2.mydomain.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=myservice.mydomain.com)))"
            driverClassName="oracle.jdbc.OracleDriver"
            maxActive="10"
            maxIdle="5"
            minIdle="2"
            maxWait="5000"
            connectionCacheName="myCache"
            connectionCachingEnabled="true"
            fastConnectionFailoverEnabled="true"
            onsConfigStr="nodes=rac1.mydomain.com:4200,rac2.mydomain.com:4200"
            connectionProperties="oracle.jdbc.ReadTimeout=30000" />

Cette datasource est accessible via le JNDI sous le nom java:comp/env/jdbc/myRacDb (sous Tomcat).

Le cluster Oracle RAC est ici composé de 2 noeuds rac1.mydomain.com et rac2.mydomain.com. On travaille avec un driver Oracle thin.

Sous tomcat, il faut mettre la librairie Oracle JDBC ons.jar (Oracle Notification Services) dans le common/lib (du moins sous tomcat 5) avec les autres librairies Oracle (ojdbc14.jar et orai18n.jar notamment).

Afin de ne pas avoir d'ennuis, il est obligatoire de mettre l'attribut nodes dans l'onsConfigString et préférable qu'il soit à l'identique de la configuration Oracle (pour cela une bonne communication avec votre DBA est nécessaire).

Nous avons surtout tâtonné pour trouver le type et la factory car la documentation n'est pas orienté tomcat mais plutôt grand serveurs d'applications commerciaux (je vous laisse deviner lesquels!).

Si vous faites des déploiements à chaud sur Tomcat (déconseillé) il est préférable d'enlever le connectionCacheName pour éviter que Tomcat se plaigne de l'existence d'un cache portant le même nom (apparemment pas de nettoyage à chaud!) : vous serez alors obligé de redémarrer votre serveur Tomcat.