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

vi commenter un bloc de code

guillaume — Fri, 27 Apr 2012 16:06:00 +0200

Après avoir essayé plusieurs trucs, j'ai enfin trouvé une solution intéressante pour commenter un bloc de code sous vi qui ne propose pas du mode visuel. Bien qu'intéressant quand on est sous vim, lorsqu'on est sur un serveur sur une configuration Apache, les choses sont tout de suite moins visuelles... L'idéal est d'utiliser les markers et la substitution :

se placer sur la première ligne du bloc de code et taper
```
ma
```
pour placer le marqueur a
positionner le curseur sur la dernière ligne du bloc à commenter
du marqueur a ('a) à la ligne courante (.) remplacer chaque début de ligne par un # :
```
:'a,.s/^/#/
```

Et voilà!

Flex "RSL error 1 of 1"

guillaume — Fri, 27 Apr 2012 14:56:00 +0200

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

Log4j : changer le niveau de log à chaud via JMX

guillaume — Tue, 31 Jan 2012 10:49:00 +0100

Changer le niveau de log directement sans avoir à redéployer l'application est parfois indispensable sur des plateformes critiques où il est impossible d'interrompre le service. C'est aussi un moyen de déboguer directement sur une plateforme qui est la seule à présenter un bug non reproductible ailleurs.

Il existe plusieurs solutions dont :

relecture de la configuration Log4j à intervalle régulier; il suffit alors de modifier la configuration des niveaux de log directement (soit avec l'API Log4j, soit avec les classes utilitaires de Spring Log4jWebConfigurer)
changement des niveaux de log à l'aide de JMX

C'est cette dernière solution que je préfère, car il est généralement déconseillé de modifier directement des fichiers à chaud dans un serveur d'applications.

Il faut d'abord créer une classe avec une méthode permettant de modifier le niveau de log de n'importe quel package :

import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import org.springframework.jmx.export.annotation.ManagedOperation;
import org.springframework.jmx.export.annotation.ManagedOperationParameter;
import org.springframework.jmx.export.annotation.ManagedOperationParameters;
import org.springframework.jmx.export.annotation.ManagedResource;

@ManagedResource(description="Log4j debug level modifier")
public class Log4jLevelChanger {

 @ManagedOperation(description = "Change log level of a package")
  @ManagedOperationParameters({
                     @ManagedOperationParameter(name = "loggerName", description = "package name"),
                    @ManagedOperationParameter(name = "level", description = "log level (DEBUG, INFO, etc.)")
 })
        public void setLogLevel(String loggerName, String level) {
                if ("debug".equalsIgnoreCase(level)) {
                    Logger.getLogger(loggerName).setLevel(Level.DEBUG);
               } else if ("info".equalsIgnoreCase(level)) {
                      Logger.getLogger(loggerName).setLevel(Level.INFO);
                } else if ("error".equalsIgnoreCase(level)) {
                     Logger.getLogger(loggerName).setLevel(Level.ERROR);
               } else if ("fatal".equalsIgnoreCase(level)) {
                     Logger.getLogger(loggerName).setLevel(Level.FATAL);
               } else if ("warn".equalsIgnoreCase(level)) {
                      Logger.getLogger(loggerName).setLevel(Level.WARN);
                } else if ("trace".equalsIgnoreCase(level)) {
                     Logger.getLogger(loggerName).setLevel(Level.TRACE);
               } else if ("off".equalsIgnoreCase(level)) {
                       Logger.getLogger(loggerName).setLevel(Level.OFF);
         } else if ("all".equalsIgnoreCase(level)) {
                       Logger.getLogger(loggerName).setLevel(Level.ALL);
         }
 }
}

On peut remarquer qu'on a déjà préparé le terrain pour Spring avec les annotations @ManagedXXX. Cette classe sera instanciée par Spring comme singleton et exposée via JMX :

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:context="http://www.springframework.org/schema/context"
     xsi:schemaLocation="
              http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
              http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">
   
<!-- RECUPERATION DU SERVEUR MBEAN DE LA PLATEFORME -->             
<bean id="mbeanServer" class="java.lang.management.ManagementFactory" factory-method="getPlatformMBeanServer" />

<!-- bean Log4jLevelChanger en singleton -->
<bean id="log4jLevelChanger" class="fr.openfarm.util.Log4jLevelChanger" />

<!-- utilisation du MBean exporter de Spring pour exposer la méthode setLogLevel dans JMX -->
<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter" lazy-init="false">
    <property name="beans">
             <map>
                       <entry key="fr.openfarm.util:name=Log4jLevelChanger" value-ref="log4jLevelChanger" />
               </map>
      </property>
 <property name="assembler" ref="metadataAssembler"/>
        <property name="namingStrategy" ref="namingStrategy"/>
</bean>       

<bean id="jmxAttributeSource" class="org.springframework.jmx.export.annotation.AnnotationJmxAttributeSource"/>
         
<bean id="namingStrategy" class="org.springframework.jmx.export.naming.MetadataNamingStrategy">
       <property name="attributeSource" ref="jmxAttributeSource"/>
   </bean>
   
<bean id="metadataAssembler" class="org.springframework.jmx.export.assembler.MetadataMBeanInfoAssembler">
       <property name="attributeSource" ref="jmxAttributeSource"/>
</bean>

On indique que les annotations seront utilisées comme source de données de configuration pour JMX avec le bean jmxAttributeSource. Ensuite, on indique que la stratégie de nommage des MBeans JMX sera faite à partir des annotations (bean namingStrategy) et que les metadata du MBean également utiliseront les annotations (bean metadataAssembler). Si les metadata ne sont pas utilisés, les noms de paramètres affichés dans la console JMX seront alors nommés arbitrairement p1 et p2.

Enfin, les deux beans namingStrategy et metadataAssembler sont passés en attribut de l'exporter qui sera chargé d'exposer le ou les MBeans dans JMX.

Voici le résultat dans JVisualVM (ou jconsole) :

Log4j avec Spring et applications multiples dans Tomcat

guillaume — Wed, 04 Jan 2012 12:15:00 +0100

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)

Voici un exemple de configuration Log4j utilisée :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration debug="true" xmlns:log4j="http://jakarta.apache.org/log4j/">

   <appender name="console" class="org.apache.log4j.ConsoleAppender">
          <param name="Target" value="System.out" />
          <layout class="org.apache.log4j.PatternLayout">
                     <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss} %p [%c] - %m%n" />
           </layout>
   </appender>
 
  <appender name="logFile" class="org.apache.log4j.DailyRollingFileAppender">
         <param name="File" value="logs/${app.ctx}.log" />
           <param name="DatePattern" value="'.'yyyy-MM-dd"/>
           <param name="Append" value="true" />
                <layout class="org.apache.log4j.PatternLayout">
                     <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss} %p [%c] - %m%n" />
           </layout>
   </appender>
 
  <appender name="monitoring" class="org.apache.log4j.DailyRollingFileAppender">
              <param name="File" value="logs/${app.ctx}_monitoring.log" />
                <param name="DatePattern" value="'.'yyyy-MM-dd"/>
           <param name="Append" value="true" />
                <layout class="org.apache.log4j.PatternLayout">
                     <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss} %p - %m%n" />
                </layout>
   </appender>
 
  <appender name="errors" class="org.apache.log4j.DailyRollingFileAppender">
          <param name="File" value="logs/${app.ctx}_errors.log" />
            <param name="DatePattern" value="'.'yyyy-MM-dd"/>
           <param name="Append" value="true" />
                <layout class="org.apache.log4j.PatternLayout">
                     <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss} %p [%c] - %m%n" />
           </layout>
   </appender>       

    <appender name="requests" class="org.apache.log4j.DailyRollingFileAppender">
                <param name="File" value="logs/${app.ctx}_requests.log" />
          <param name="DatePattern" value="'.'yyyy-MM-dd"/>
           <param name="Append" value="true" />
                <layout class="org.apache.log4j.PatternLayout">
                     <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss} %p [%c] - %m%n" />
           </layout>
   </appender>       
          
  <logger name="org.apache.catalina" additivity="false">
              <level value="INFO" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>

     <logger name="org.apache.jasper" additivity="false">
                <level value="INFO" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>

     <logger name="org.springframework" additivity="false">
              <level value="INFO" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>
   
  <logger name="org.hibernate" additivity="false">
            <level value="INFO" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>

     <logger name="org.hibernate.cfg" additivity="false">
                <level value="WARN" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>
   
  <logger name="org.codehaus.xfire" additivity="false">
               <level value="INFO" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>
   
  <logger name="org.codehaus.xfire.spring.remoting.Jsr181HandlerMapping" additivity="false">
          <level value="FATAL" />
             <appender-ref ref="errors" />
               <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>

     <logger name="org.codehaus.xfire.handler.DefaultFaultHandler" additivity="false">
           <level value="INFO" />
              <appender-ref ref="errors" />
               <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>
           
  <logger name="net.sf.ehcache" additivity="false">
           <level value="INFO" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>
   
  <logger name="org.apache.commons.httpclient" additivity="false">
            <level value="INFO" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>

     <logger name="org.apache.commons.beanutils.BeanUtils" additivity="false">
           <level value="WARN" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>

     <logger name="org.apache.commons.beanutils.PropertyUtils" additivity="false">
               <level value="WARN" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>
   
  <logger name="org.apache.commons.digester" additivity="false">
              <level value="WARN" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>

     <logger name="org.hibernate.cache" additivity="false">
              <level value="INFO" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>

     <logger name="net.sf.ehcache.hibernate" additivity="false">
         <level value="INFO" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>

     <logger name="freemarker.cache" additivity="false">
         <level value="INFO" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>

     <logger name="freemarker.bean" additivity="false">
          <level value="WARN" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>
 
    <logger name="fr.openfarm" additivity="false">
              <level value="DEBUG" />
             <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>

     <logger name="fr.openfarm.service.impl.ServiceImpl" additivity="false">
             <level value="INFO" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>

     <logger name="fr.openfarm.service.impl.ServiceImpl2" additivity="false">
            <level value="INFO" />
              <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>

     <logger name="fr.openfarm.domain.model.HibernateSchemaInterceptor" additivity="false">
              <level value="DEBUG" />
             <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>
                                                   
  <logger name="fr.openfarm.service.exception" additivity="false">
            <level value="INFO" />
              <appender-ref ref="errors" />
               <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger>

     <logger name="fr.openfarm.ws.fault" additivity="false">
             <level value="INFO" />
              <appender-ref ref="errors" />
               <appender-ref ref="logFile" />
              <appender-ref ref="console" />
      </logger> 

    <logger name="fr.openfarm.aop.PerformanceProfilerAspect" additivity="false">
                <level value="INFO" />
              <appender-ref ref="console" />
              <appender-ref ref="logFile" />
              <appender-ref ref="requests"/>
              <appender-ref ref="monitoring"/>
    </logger>
            
 <root>
              <priority value="INFO" />
           <appender-ref ref="console" />
              <appender-ref ref="logFile" />
      </root>
     
</log4j:configuration>

La configuration est ensuite activée par Spring au niveau du fichier web.xml grâce au org.springframework.web.util.Log4jConfigListener pour lequel il faut ajouter le paramètre log4jConfigLocation qui indique où se trouve le fichier de configuration log4j. Dans notre cas, ce nom de fichier est paramétré grâce à une variable d'environnement java "env" que l'on passera à la JVM (ex: -Denv=preprod pour choisir le fichier log4j-preprod.xml ) et l'on considère que les niveaux de logs n'auront pas à être différenciés. Les deux applications étant à l'intérieur du même serveur Tomcat, donc la même JVM, partagerons donc le même fichier de log log4j-${env}.xml


<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
      version="2.4">

   <display-name>OPENFARM WebServices</display-name>
     
  <context-param>
            <param-name>log4jConfigLocation</param-name>
         <param-value>/WEB-INF/classes/log4j-${env}.xml</param-value>
 </context-param>
    
  <context-param>
             <param-name>contextConfigLocation</param-name>
                <param-value>
                       classpath:applicationContext.xml,
                 classpath:applicationContext-hibernate.xml,
                       /WEB-INF/xfire-servlet.xml
                </param-value>
      </context-param>

     <listener>
         <listener-class>
                   org.springframework.web.util.Log4jConfigListener
         </listener-class>
  </listener>
    
       <listener>
          <listener-class>
                    org.springframework.web.context.ContextLoaderListener
             </listener-class>
   </listener>

   <!-- XFire SOAP servlets -->
        <servlet>
           <servlet-name>xfire</servlet-name>
            <servlet-class>
                     org.codehaus.xfire.spring.XFireSpringServlet
              </servlet-class>
    </servlet>
  <servlet-mapping>
           <servlet-name>xfire</servlet-name>
            <url-pattern>/services/*</url-pattern>
        </servlet-mapping>

    <resource-ref>
        <description>SYCAR database</description>
     <res-ref-name>jdbc/mydb</res-ref-name>
        <res-ref-type>javax.sql.DataSource</res-ref-type>
     <res-auth>Container</res-auth>
      </resource-ref>
     
  <!-- Compress SOAP servlets -->
     <filter>
            <filter-name>CompressingFilter</filter-name>
          <filter-class>
                      com.planetj.servlet.filter.compression.CompressingFilter
          </filter-class>
             <init-param>
                        <param-name>debug</param-name>
                        <param-value>true</param-value>
               </init-param>
               <init-param>
                        <param-name>statsEnabled</param-name>
                 <param-value>true</param-value>
               </init-param>
       </filter>
   <filter-mapping>
            <filter-name>CompressingFilter</filter-name>
          <url-pattern>/services/*</url-pattern>
        </filter-mapping>

     <welcome-file-list>
         <welcome-file>index.html</welcome-file>
       </welcome-file-list>
</web-app>

Cette configuration appliquée aux deux applications présente un premier problème : les noms des fichier de log des appenders ne peuvent pas être identiques si l'on veut que les logs soient bien séparées pour chaque application. On remarquera d'ailleurs que nous avons mis logs/${app.ctx}_*.log pour les noms de fichier. En effet, la seule possibilité est de générer un fichier log4j différent selon le contexte de l'application à la compilation. Pour cela nous utilisons les filtres maven qui permettent d'effectuer des remplacements dans les fichiers textes. Il faut ajouter quelques éléments de configuration à plusieurs endroits dans notre fichier pom.xml :

D'abord au niveau du plugin war pour qu'il applique le filtrage et fasse le remplacement des properties / variables passées à maven dans le fichier web.xml :

             <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                   <artifactId>maven-war-plugin</artifactId>
                     <version>2.1.1</version>
                              <configuration>
                                     <!-- filtrage du fichier web.xml pour injecter la valeur app.ctx -->
                                        <filteringDeploymentDescriptors>true</filteringDeploymentDescriptors>
                         </configuration>
            </plugin>

Ensuite au niveau de la gestion des fichiers ressources pendant la phase de compilation pour qu'il applique le filtrage et fasse le remplacement des properties / variables passées à maven dans les fichiers xml ou properties. On notera d'ailleurs que le tag <finalName> prend aussi la valeur ${app.ctx} puisque c'est le nom du contexte web de l'appli.

     <build>
             <!-- le nom du contexte de l'application est passé en paramètre -->
         <finalName>${app.ctx}</finalName>
             <resources>
                 <!-- filtrage des fichiers ressources log4j.xml et *.properties -->
                 <resource>
                          <directory>src/main/resources</directory>
                             <filtering>true</filtering>
                           <includes>
                                          <include>**/*.xml</include>
                                   <include>**/*.properties</include>
                            </includes>
                 </resource>
                 <!-- pas de filtrage pour les autres fichiers notamment binaires -->
                        <resource>
                          <directory>src/main/resources</directory>
                             <filtering>false</filtering>
                          <excludes>
                                          <exclude>**/*.xml</exclude>
                                   <exclude>**/*.properties</exclude>
                            </excludes>
                 </resource>
         </resources>
        [...]

       </build>

ATTENTION : il faut prendre quelques précautions avec les filtres maven, notamment en ajoutant une section ne filtrant pas les autres fichiers binaires sous peine de corrompre ceux-ci puisque maven recopie ces fichiers en les considérant comme des fichiers textes!

Il suffit alors de compiler les deux applications comme suit :


$ mvn -Dapp.ctx=my-app1 clean package
$ mvn -Dapp.ctx=my-app2 clean package

On peut alors constater qu'il y a bien eu modification des noms des fichiers de log pour chacune des applications my-app1 et my-app2. Cependant lors de l'exécution, on s'aperçoit qu'une seule des applications est logguée et que l'erreur suivante apparait :


Exception lors de l'envoi de l'événement contexte initialisé (context initialized) à  l'instance de classe d'écoute (listener) org.springframework.web.util.Log4jConfigListener
java.lang.IllegalStateException: Web app root system property already set to different value: 'webapp.root' = [/tomcat-webapps/my-app2/] instead of [/tomcat-webapps/my-app1/] - Choose unique values for the 'webAppRootKey' context-param in your web.xml files!
    at org.springframework.web.util.WebUtils.setWebAppRootSystemProperty(WebUtils.java:132)
    at org.springframework.web.util.Log4jWebConfigurer.initLogging(Log4jWebConfigurer.java:117)
    at org.springframework.web.util.Log4jConfigListener.contextInitialized(Log4jConfigListener.java:51)
    at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3729)
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:4187)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
    at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:608)
    at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:535)
    at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470)
    at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122)
    at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
    at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021)
    at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
    at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
    at org.apache.catalina.core.StandardService.start(StandardService.java:450)
    at org.apache.catalina.core.StandardServer.start(StandardServer.java:709)
    at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
    at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)

En regardant la documentation Spring sur Log4jWebConfigurer, on peut lire la mise en garde suivante :

WARNING: Some containers (like Tomcat) do not keep system properties separate per web app. You have to use unique "webAppRootKey" context-params per web app then, to avoid clashes. Other containers like Resin do isolate each web app's system properties: Here you can use the default key (i.e. no "webAppRootKey" context-param at all) without worrying

Il faut donc ajouter ce paramètre dans le web.xml en y mettant le nom du contexte applicatif ${app.ctx} de façon à ce que le paramètre webAppRootKey soit unique :

     <context-param>
             <param-name>webAppRootKey</param-name>
                <param-value>${app.ctx}</param-value>
 </context-param>

D'autre part, il ne faut pas non plus oublier de configurer le mode de gestion des properties dans Spring et notamment celles des system properties. En effet, il faut indiquer à Spring si les properties du système doivent écraser les valeurs pouvant être définies dans le contexte Spring. Ceci ce fait grâce au PropertyPlaceholderConfigurer avec la propriété systemPropertiesModeName qui peut prendre plusieurs valeurs :

     <bean id="propertyConfigurer"
          class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
                <property name="locations">
                 <list>
                              <value>classpath:/jdbc.properties</value>
                             <value>classpath:/hib3.properties</value>
                             <value>classpath:/myapp.properties</value>
                    </list>
             </property>
         <property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE"/>
 </bean>

En utilisant la valeur SYSTEM_PROPERTIES_MODE_OVERRIDE , Spring vérifiera d'abord les system properties en premier avant tout autre property spécifiée par ailleurs.

Sources :

http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/web/util/Log4jWebConfigurer.html

http://tai-dev.blog.co.uk/2008/08/07/glassfish-spring-multiple-applications-p-4555617/

http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html

http://maven.apache.org/plugins/maven-war-plugin/faq.html#filtering

commande find : trouver les derniers fichiers modifiés à partir d'une certaine date

guillaume — Fri, 18 Nov 2011 23:33:00 +0100

La commande find est très puissante mais il faut parfois creuser un peu pour trouver la bonne syntaxe...

Pour trouver tous les fichiers réguliers modifiés dans les dernières 24 heures dans un répertoire et ses sous-répertoire voici la commande :

find /mydir -type f -mtime -1 -print

Pour trouver tous les fichiers réguliers modifiés à partir du début de la journée dans un répertoire et ses sous-répertoire il faut ruser un peu...

On créée d'abord un fichier factice à l'aide de la commande touch en forçant la date de ce dernier :


$ touch -t `date +%m%d0000` /tmp/$$
$ ls -l /tmp/
-rw-r--r-- 1 moi moi 0 2011-11-18 00:00 5992
$ find /mydir -type f -newer /tmp/5992
$ rm /tmp/5992

En effet dans la documentation de la commande touch on lit ceci sur l'option -t :

-t STAMP use [[CC]YY]MMDDhhmm[.ss] instead of current time

Il est donc ensuite très facile d'étendre la commande précédente pour lui faire rechercher des fichiers après n'importe quelle date.

OFBiz : affichage d'une chaine HTML avec Freemarker

guillaume — Tue, 27 Sep 2011 09:50:00 +0200

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.

Audit des requêtes SQL Hibernate

guillaume — Tue, 23 Aug 2011 15:03:00 +0200

Obtenir les traces des prepared statements d'Hibernate est assez simple et tout le monde connaît cette configuration. Il suffit d'indiquer

hibernate.show_sql=true

dans le fichier de configuration XML Hibernate pour obtenir la requête qui sera utilisé avec le SGBD. La requête sera affichée sous la forme d'un preparedStatement avec des "?" à la place des valeurs.

Une question alors fréquemment posée est : comment obtenir aussi les valeurs passée avec la requête?!

L'information est quelque part connue en interne dans Hibernate : le tout est de la mettre en valeur en modifiant le paramétrage du logger. Par exemple avec log4j il suffit de mettre en level DEBUG les packages suivants et de les router vers un appender spécifique avec une additivité à false :

log4j.logger.org.hibernate.SQL=DEBUG,SQL_APPENDER
log4j.additivity.org.hibernate.SQL=false
org.hibernate.type=DEBUG,SQL_APPENDER
log4j.additivity.org.hibernate.type=false

bzip2 gzip tar avec stdin et stdout

guillaume — Tue, 03 May 2011 15:39:00 +0200

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

Maven récupération du code source et de la javadoc

guillaume — Wed, 02 Mar 2011 11:15:00 +0100

Pour récupérer les codes sources et la javadoc, il suffit d'ajouter au lancement de maven

-DdownloadSources=true -DdownloadJavadocs=true

ou bien ceci dans le pom.xml

<properties>

     <downloadSources>true</downloadSources>

     <downloadJavadocs>true</downloadJavadocs>

     ....

</properties>

Il est utile d'avoir les sources lors des phases de debugging pour comprendre parfois le comportement d'un framework.

Message Bundle avec Spring et problèmes d'encodage des fichiers de properties

guillaume — Tue, 22 Feb 2011 18:23:00 +0100

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

Données utilisateur visualVM

guillaume — Thu, 17 Feb 2011 16:11:00 +0100

Lors d'un changement de JVM, il se peut que les données de configuration VisualVM ne soient pas récupérées (notamment passage de Java 6 à Java 7). Sur un poste windows, il est très simple de récupérer ses configurations d'hôtes à monitorer. Elles se trouvent dans :

C:\Documents and Settings\utilisateur\Application Data\.visualvm\6u30

Les hôtes déclarés sont dans le répertoire repository. Il suffit de recopier les données vers le répertoire C:\Documents and Settings\utilisateur\Application Data\.visualvm\7 si vous venez d'installer la dernière JVM 7.

D'une version 6 à une autre, le premier répertoire créé semble être conservé pour les versions suivantes.

Problème avec le Maven archetype plugin

guillaume — Wed, 16 Feb 2011 16:12:00 +0100

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à!

Archetype maven et quickstart pour spring batch

guillaume — Wed, 16 Feb 2011 11:57:00 +0100

Les archetypes maven ne semblent pas très fonctionnels... Pour créer un template de projet à partir d'un archetype existant voici la commande à exécuter :

$ mvn archetype:generate

Maven sort alors une liste d'une vingtaines d'archetypes possibles. On peut alors choisir l'archetype à utiliser et le customiser. Maven génère alors un répertoire projet prêt à l'emploi. En les testant on s'aperçoit que sur la majorité des archetypes disponibles, seuls quelques uns fonctionnent vraiment...
La liste des archetypes possibles se trouve ici : http://docs.codehaus.org/display/MAVENUSER/Archetypes+List
C'est un peu décevant...

De même, j'ai cherché un archetype pour Spring-batch. Visiblement rien n'existe et l'infrastructure maven ne semble pas être utilisée pour ça. Le mieux que j'ai trouvé c'est d'aller directement récupérer les exemples de code qui existent sur le repository SVN de spring !

$ svn export https://src.springframework.org/svn/spring-batch/trunk/archetypes/simple-cli
$ cd simple-cli
$ mvn test

Et voilà! On y trouvera aussi d'autres exemples de projet.

Uptime d'un serveur

guillaume — Wed, 15 Dec 2010 17:28:00 +0100

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.

SOAPUI connexion JDBC

guillaume — Tue, 30 Nov 2010 11:28:00 +0100

Pour réaliser des tests plus industriels, il est nécessaire que le script de test puisse accéder à une base de données. Sur la version non payante de SOAPUI

import com.eviware.soapui.*;
import groovy.sql.Sql;

def dbUrl = "jdbc:oracle:thin:@(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = host1.mydomain.com)(PORT = 1523))(ADDRESS = (PROTOCOL = TCP)(HOST = host2.mydomain.com
)(PORT = 1521))(FAILOVER = false))(CONNECT_DATA =(SERVICE_NAME = MYDB.MYDOMAIN.COM)))";
def dbUser = "user";
def dbPwd = "mypassword";
def sql;
try {
    sql = Sql.newInstance(dbUrl, dbUser, dbPwd, "oracle.jdbc.OracleDriver");
    //def res = sql.firstRow("SELECT * FROM MA_TABLE");
    //log.info res.ID + " " + res.CHAMP1;
    //res.close();
    sql.eachRow("SELECT * FROM MA_TABLE") {
            log.info "${it.ID} / ${it.CHAMP1}"
    }
    sql.close();
    log.info "Closed Database Connection.";
} catch (Exception e) {
    log.error "Could not establish connection to the database.";
}

Voilà une première étape de franchie. On peut aller plus loin en utilisant ceci au niveau des scripts de setup et tear down d'un jeu de test.

Hibernate interceptor : nom de schéma dynamique

guillaume — Sun, 07 Nov 2010 23:15:00 +0100

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

Les interceptors d'Hibernate permettent d'intervenir au niveau des opérations réalisées au niveau des entités. La capture ci-dessous permet de voir la liste des méthodes qu'il est possible de surcharger :

Dans le cas qui nous intéresse, nous allons surcharger la méthode onPrepareStatement(String) sur un héritage de la classe EmptyInterceptor d'Hibernate car c'est à cet endroit qu'il est possible de modifier à la volée les requêtes réalisées par Hibernate sur l'entité.
En supposant que le schéma de l'environnement est connu par l'intermédiaire d'une propriété système Java "env" (ex: -Denv=SCHEMA_PROD), on peut alors à l'exécution remplacer à la volée le nom du schéma par le schéma d'environnement uniquement pour l'objet Etat, c'est à dire pour l'entité pointant sur la table ETAT. Dans toute la requête SQL fabriquée par Hibernate, on aura alors remplacé tous les MON_SCHEMA.ETAT par SCHEMA_PROD.ETAT.

import org.hibernate.EmptyInterceptor;

public class SchemaInterceptor extends EmptyInterceptor {

    @Override
    public String onPrepareStatement(String sql) {
        String pstmt = super.onPrepareStatement(sql);
        String schema = System.getProperty("env");
        if( pstmt.matches("MON_SCHEMA.ETAT")) {
            pstmt = pstmt.replaceAll("MON_SCHEMA.ETAT", schema + ".ETAT");
        }
        return pstmt;
    }
}

Ensuite, il faut intégrer l'intercepteur dans la sessionFactory Hibernate (contexte Spring) :

<bean id="schemaInterceptor" class="fr.openfarm.hibernate.interceptors.SchemaInterceptor"/>

<bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
     <property name="dataSource">...</property>
     ...
     <property name="entityInterceptor">
         <ref bean="schemaInterceptor"/>
     </property>
</bean>

Attention : on ne peut déclarer qu'un seul intercepteur par session.
Les sources ci-dessous donnent d'autres exemples d'utilisation des intercepteurs (audit des entités ou la sécurité) :

Tomcat : configuration proxy HTTPS

guillaume — Wed, 13 Oct 2010 12:24:00 +0200

La configuration d'un proxy HTTPS pour Tomcat est plus cohérente que celle de maven et plus directe; il suffit juste d'indiquer les propriétés système de Java dans le fichier $CATALINA_HOME/conf/catalina.properties :

http.proxyHost=proxy.mydomain.com
http.proxyPort=8080
http.nonProxyHost=localhost|10.*

https.proxyHost=proxy.mydomain.com
https.proxyPort=8080

Maven : configuration proxy HTTPS

guillaume — Wed, 13 Oct 2010 12:08:00 +0200

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

Implémentation d'un Interceptor CXF pour logger le temps d'exécution

guillaume — Mon, 04 Oct 2010 11:59:00 +0200

Les intercepteurs de CXF permettent, comme leur nom l'indique, d'intercepter le flux en entrée ou en sortie d'un webservice et d'exécuter un traitement. Tout comme les filtres de servlet, ils sont puissant pour réaliser des opérations techniques sur les données.

Si l'on veut tracer le temps d'exécution d'un webservice à toutes les étapes et notamment juste avant l'entrée dans l'implémentation.

Implémentation d'intercepteurs CXF

L'implémentation d'un intercepteur est assez simple. Il suffit d'implémenter l'interface Interceptor. Plusieurs implémentation abstraite existent pour faciliter la tâche. Les deux plus fréquentes sont AbstractPhaseInterceptor et AbstractSoapInterceptor qui permettent d'accéder au Message ou au SoapMessage.

Le premier intercepteur créé va permettre la prise de date du démarrage de l'appel au web service et devra être placé en input. On démarre le ExecTimeCalculator dans la méthode handleMessage.

import org.apache.cxf.interceptor.Fault;
import org.apache.cxf.message.Message;
import org.apache.cxf.phase.AbstractPhaseInterceptor;
import org.apache.cxf.phase.Phase;

public class LogInTimeInterceptor extends AbstractPhaseInterceptor<Message> {

    public LogInTimeInterceptor() {
        super(Phase.RECEIVE);
    }
    public void handleMessage(Message message) throws Fault {
        ExecTimeCalculator.getInstance().start();
    }
}

Le deuxième intercepteur va s'occuper de récupérer le nom du service et de l'opération appelée, et les envoyer à l'ExecTimeCalculator pour arrêter la date de fin d'exécution et afficher le service, l'opération et le temps total d'exécution.

import javax.xml.namespace.QName;

import org.apache.cxf.interceptor.Fault;
import org.apache.cxf.message.Message;
import org.apache.cxf.phase.AbstractPhaseInterceptor;
import org.apache.cxf.phase.Phase;

public class LogOutTimeInterceptor extends AbstractPhaseInterceptor<Message> {
    
    //private static final Logger logger = Logger.getLogger(LogOutTimeInterceptor.class);
    
    public LogOutTimeInterceptor() {
        super(Phase.SEND);
    }
    
    public void handleMessage(Message message) throws Fault {
        QName service = (QName) message.get(Message.WSDL_SERVICE);
        QName op = (QName) message.get(Message.WSDL_OPERATION);
        ExecTimeCalculator.getExecTime(service.getLocalPart(), op.getLocalPart());
    }

}

Configuration du webservice avec les intercepteurs

La configuration dans le contexte Spring CXF du webservice se fait très simplement avec en plus des sections <jaxws:inInterceptors> et <jaxws:outInterceptors> dans laquelle on va rajouter nos intercepteurs :

    <bean id="serviceImpl" class="fr.openfarm.wss.ServiceTestImpl"/>
    <bean id="logInTime" class="fr.openfarm.wss.LogInTimeInterceptor"/>
    <bean id="logOutTime" class="fr.openfarm.wss.LogOutTimeInterceptor"/>

    <jaxws:endpoint id="service" implementor="#serviceImpl"
        implementorClass="fr.openfarm.wss.ServiceTestImpl"
        address="/ServiceTest">
        <jaxws:inInterceptors>
            <ref bean="logInTime"/>
        </jaxws:inInterceptors>
        <jaxws:outInterceptors>
            <ref bean="logOutTime"/>
        </jaxws:outInterceptors>
    </jaxws:endpoint>

Calcul du temps d'exécution

Ce temps d'exécution nous avons pouvoir le calculer grâce à une variable en ThreadLocal mise dans un singleton... On va stocker un objet Calendar sous la forme d'un ThreadLocal. Ceci signifie que lorsqu'ExecTimeCalculator est appelé par un thread, l'objet Calendar sera affecté à ce thread et à lui seul. Chaque thread garde donc une copie propre de l'objet Calendar par l'intermédiaire du ThreadLocal. Etant donné que l'input et l'output d'une requête de web service se fait dans le même thread, on peut alors calculer le temps d'exécution si l'on stocke la date de démarrage.

import java.text.SimpleDateFormat;
import java.util.Calendar;
import org.apache.log4j.Logger;

public class ExecTimeCalculator {
    
    private static final Logger logger = Logger.getLogger(ExecTimeCalculator.class);
    private static final SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss");
    
    private static ExecTimeCalculator instance;
    private ThreadLocal<Calendar> date;
    
    private ExecTimeCalculator() {
        this.date = new ThreadLocal<Calendar>();
        this.date.set(null);
    }
    
    public static ExecTimeCalculator getInstance() {
        if( instance == null ) instance = new ExecTimeCalculator();
        return instance;
    }
    
    public void start() {
        Calendar now = Calendar.getInstance();
        getInstance().date.set(now);
        logger.debug("Date début exec : " + sdf.format(now.getTime()) 
                + " [ threadId = " + Thread.currentThread().getId() + "]");
    }
    
    public static void getExecTime(String service, String operation) {
        Calendar now = Calendar.getInstance();
        logger.debug("Date fin exec : " +sdf.format(now.getTime())
                 + " [ threadId = " + Thread.currentThread().getId() + "]");
        logger.info(service + "." + operation + " : execution time = "
                + (now.getTimeInMillis() - getInstance().getDate().get().getTimeInMillis())
                + " ms");
        getInstance().getDate().set(null);
    }

    public ThreadLocal<Calendar> getDate() {
        return date;
    }

    public void setDate(ThreadLocal<Calendar> date) {
        this.date = date;
    }

}

A vous de jouer!

Source :

http://www.jroller.com/gmazza/entry/jaxwshandlers_to_cxfinterceptors

https://cwiki.apache.org/CXF20DOC/interceptors.html

Spring AOP advice et pointcut sur Servlet

guillaume — Sat, 02 Oct 2010 23:37:00 +0200

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.

Mon besoin initial consistait à calculer le temps d'exécution des servlets CXF pour des webservices.

L'astuce consiste à créer un filtre de servlet. Mais les filtres sont aussi gérés par le conteneur me direz-vous?! Oui mais il est possible de raccrocher ces filtres au contexte spring de 2 façons :

La première solution

consiste à raccrocher le filtre au contexte spring lors de l'initialisation du filtre :

public class SpringAwareFilter implements Filter {
@Autowire MyBean myBean;
public void destroy(...) { ... }
public void doFilter(...) {
       ....
        myBean.methodeToIntercept(...);
       ....
}
public void init(FilterConfig filterConfig) throws ServletException {
        ServletContext servletContext = filterConfig.getServletContext();
        WebApplicationContext webApplicationContext = WebApplicationContextUtils.getWebApplicationContext(servletContext);      
        AutowireCapableBeanFactory autowireCapableBeanFactory = webApplicationContext.getAutowireCapableBeanFactory();
        autowireCapableBeanFactory.configureBean(this, "myBean");
}

Une fois le filtre accroché au contexte Spring, il est possible d'ajouter le pointcut sur methodToIntercept du bean Spring myBean.

Source : http://forum.springsource.org/showthread.php?t=60983

La deuxième solution

est d'utiliser directement la classe Spring DelegatingFilterProxy qui fait sensiblement la même chose.

On crée d'abord un filtre en implémentant Filter de la façon suivante :

package fr.openfarm.aop;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;


public class ServletPointcutFilter implements Filter {

    @Override
    public void destroy() {
        // cette partie "lifecycle" du filtre  est normalement prise en charge
        // par la classe org.springframework.web.filter.DelegatingFilterProxy
        // déclarée dans le web.xml
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException {
        // filtre identité que ne à rien d'autre que donner la main
        // au filtre de servlet suivant
        // c'est cette méthode publique qui va pouvoir être interceptée
        // et donc utilisée comme pointcut par Spring AOP
        chain.doFilter(request, response);
    }

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        // cette partie "lifecycle" du filtre  est normalement prise en charge
        // par la classe org.springframework.web.filter.DelegatingFilterProxy
        // déclarée dans le web.xml
    }

}

Ensuite, il faut déclarer ce filtre comme un bean spring :

<bean id="servletPointcutFilter" class="fr.openfarm.aop.ServletPointcutFilter"/>

Visible du contexte Spring, il peut alors être candidat aux advices.

Il faut ensuite déclarer le filtre DelegatingFilterProxy de Spring et son application dans le fichier web.xml :

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">

    <display-name>CXF WS-S</display-name>

    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>
            classpath:applicationContext.xml
        </param-value>
    </context-param>

    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
    
    <!-- Il est impossible d'intercepter les servlets par Spring AOP
        car elles sont hors contexte spring
        l'astuce consiste à appliquer un filtre de servlet sur les CXF Servlets
        grâce au filtre DelegatingFilterProxy qui s'enregistre dans le contexte spring
        et qui déléguera au filtre déclaré comme bean servletPointcutFilter 
     -->
    <filter>
       <filter-name>servletPointcutFilter</filter-name>
       <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    </filter>

    <filter-mapping>
       <filter-name>servletPointcutFilter</filter-name>
       <servlet-name>CXFServlet</servlet-name>
    </filter-mapping>
    
    <servlet>
        <servlet-name>CXFServlet</servlet-name>
        <display-name>CXF Servlet</display-name>
        <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>CXFServlet</servlet-name>
        <url-pattern>/services/*</url-pattern>
    </servlet-mapping>
    
    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
    </welcome-file-list>
        
</web-app>

Toujours fidèle à la devise "convention over configuration", il faut utiliser comme valeur de <filter-name> dans le fichier web.xml l'identifiant du bean déclaré dans Spring. Le DelegatingFilterProxy s'enregistre auprès du context Spring et fera office de Filtre proxy en appelant notre servletPointcutFilter.

Le filtre de servlet d'exécutant systématiquement avec les servlets, on a donc un moyen de s'insérer dans le fil d'exécution, à défaut d'être au plus près de la servlet. Comme dans la première méthode, on peut alors appliquer un advice sur le filtre de servlet avec par exemple l'advice @Around et le pointcut suivant :

@Aspect
public class TimeLoggerAspect {

    @Pointcut("execution(public void fr.openfarm.aop.ServletPointcutFilter.doFilter(..))")
    public void servlet() {}

    @Around("servlet()")
    public void logTimeExec() { ... }

}

Source :

http://forum.springsource.org/showthread.php?t=58083

Sinon un très bon article sur AOP AOP : mythes et réalités ( http://www.ibm.com/developerworks/java/library/j-aopwork15/ )

Spring AOP : trouver le bon pointcut avec la stack trace

guillaume — Sat, 02 Oct 2010 22:11:00 +0200

Il est parfois difficile d'identifier le bon endroit pour une "coupe" (pointcut), et il ne faut pas perdre de vue qu'une méthode protected ne pourra jamais être interceptée par Spring AOP.

J'ai donc écris ce bout de code pour me faciliter la tâche et identifier plus aisément quelle pourrait être la méthode déclarée en public et donc candidate au pointcut.

Ce code est à placer dans la méthode qui sera appelée en dernier dans le fil d'exécution afin d'avoir une liste complète des méthodes pouvant être interceptée

        // récupération d'une trace de la pile pour notre thread courant
        StackTraceElement[] stack = Thread.getAllStackTraces().get(Thread.currentThread());
        
        for(StackTraceElement ste : stack) { // on parcourt la pile
            // on parcours la liste de toutes les méthodes pour la classe
            // trouvée dans la stack trace et l'on vérifie si la méthode
            // utilisée dans la stacktrace est bien publique
            Method[] methods = Class.forName(ste.getClassName()).getMethods();
            for(Method m : methods) {
                if(m.getName().equals(ste.getMethodName())) {
                    if(Modifier.isPublic(m.getModifiers()) ) {
                        logger.debug( ste.getClassName() + "." + ste.getMethodName() );
                    }
                }
            }
        }

Erreur classique de JAXB : JAXBException nor any of its super class is known to this context

guillaume — Fri, 01 Oct 2010 22:42:00 +0200

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

Web services securisés avec CXF et WSS4J (partie 1)

guillaume — Mon, 13 Sep 2010 09:37:00 +0200

La sécurisation des webservices devient de plus en plus nécessaire dans le monde de l'entreprise. Il y a une époque pas si lointaine, les entreprises ne se souciaient pas trop de la sécurisation de leurs données à l'intérieur de l'entreprise. Or il s'avère que les risques sécuritaires viennent majoritairement de l'intérieur!

Voici donc un tutoriel qui explique comment mettre en place toute l'infrastructure webservice : serveur et client. Nous utiliserons CXF qui nous parait être une des solutions les plus efficaces et maniables. CXF allie performances et simplicité d'intégration avec la plupart des frameworks (Spring et WSS4J).

Etape 1 : création d'un webservice SOAP / HTTP

a) création du projet

Le serveur de webservices (WS) sera en fait une webapp qui exposera un fichier WSDL et qui répondra aux requêtes exprimées en SOAP. Pour un début nous allons faire dans l'originalité et faire un WS HelloWorld. Dans un deuxième temps, nous en ferons un plus complexe en terme de structure données.

On commence par créer un nouveau projet sous eclipse. On utilise maven pour construire et packager l'application. J'utilise la structure classique des répertoires de maven avec src/main/java et src/main/resources pour les sources et target/ pour les builds.

Dans le fichier pom.xml on y met les dépendances CXF et SL4J :

cxf-rt-frontend-jaxws
cxf-rt-transports-http
slf4j-api
slf4j-log4j12

A l'heure ou j'écris les versions suivantes sont utilisées (à mettre en fin du pom.xml) :

<properties>

       
<spring.version>2.5.6</spring.version>

       
<cxf.version>2.2.9</cxf.version>

       
<sl4j.version>1.6.1</sl4j.version>

  </properties>

La version de spring est donnée juste à titre indicatif car c'est celle utilisée par CXF (les librairies spring-core, spring-context, spring-beans, spring-web sont utilisées).

b) définition et implémentation du service

La définition et création du service est très rapide avec les annotations JAX-WS. L'interface est la suivante :

package fr.openfarm.helloworld.wss;



import javax.jws.WebMethod;

import javax.jws.WebService;

import javax.jws.WebParam;



@WebService

public interface HelloWorldWss {

    @WebMethod

    public String sayHi(@WebParam(name="text")String
text);

}

L'annotation @WebService est l'annotation minimale. Cependant, pour éviter de rendre les paramètres anonymes dans la génération à la volée du WSDL, il est conseillé d'ajouter @WebMethod et @WebParam afin de forcer le nommage.
L'implémentation est tout aussi rapide :

package fr.openfarm.helloworld.wss;



import javax.jws.WebService;



import org.apache.log4j.Logger;



@WebService(endpointInterface =
"fr.openfarm.helloworld.wss.HelloWorldWss")

public class HelloWorldWssImpl implements HelloWorldWss {

   

    static final Logger logger =
Logger.getLogger(HelloWorldWssImpl.class);

   

    public String sayHi(String text) {

        StringBuilder sb = new
StringBuilder("Hello");

        sb.append(text);

        logger.debug(sb.toString());

        return sb.toString();

    }



}

c) configuration Spring et CXF

Une fois cette (superbe) implémentation réalisée, il faut configurer CXF , le contexte Spring et le contexte web.
Voici le contenu du fichier src/main/resources/applicationContext.xml minimal (dans le cas d'un client comme on le verra plus loin) auquel on aura ajouté un élément jaxws:endpoint qui définira notre web service.

<beans xmlns="http://www.springframework.org/schema/beans"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

   
xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"

    xmlns:jaxws="http://cxf.apache.org/jaxws"

    xsi:schemaLocation="

http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd

http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd

http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">



    <import resource="classpath:META-INF/cxf/cxf.xml"
/>

    <import
resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />

    <import resource="classpath:META-INF/cxf/cxf-servlet.xml"
/>

   

    <jaxws:endpoint id="helloWorld"

       
implementor="fr.openfarm.helloworld.wss.HelloWorldWssImpl"

        address="/HelloWorld"

       
xmlns:e="http://service.jaxws.cxf.apache.org/endpoint"

       
xmlns:s="http://service.jaxws.cxf.apache.org/service"/>

   

</beans>

Afin de pouvoir utiliser cette notation, il est important de bien ajouter les namespaces xmlns:jaxws et xmlns:http-conf dans l'entête. D'autre part, il ne faut pas oublier de mettre les XSD de spring 2.5 dans schemaLocation, sinon vous risquez d'obtenir cette erreur : The prefix "jaxws" for element "jaxws:endpoint" is not bound. Elle peut vite arriver si vous vous fiez à la documentation CXF qui n'est pas toujours à jour.
Les xmlns:e et xmlns:s sont ajoutés pour mémoire au cas où l'on souhaite personnaliser le nommage du endpoint et du service par l'intermédiare des attributs endpoint et service dans la balise <jaxws:endpoint>.
Les trois directives import chargent les fichiers de configuration CXF supplémentaires. Pour le moment ces fichiers n'existent pas.

d) configuration webapp et logs

Pour log4j (via API SL4L) il est nécessaire d'ajouter un fichier de configuration minimum pour les logs dans src/main/resources

log4j.rootCategory=WARN, CONSOLE

log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender

log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout

log4j.appender.CONSOLE.layout.ConversionPattern=[%d{ABSOLUTE} %-5p %c{1}]:
%m%n

log4j.logger.fr.openfarm=DEBUG

Ensuiite le fichier web.xml devra être comme suit :



<?xml version="1.0" encoding="UTF-8"?>



<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

   
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"

    version="2.4">



    <display-name>Hello World
WSS</display-name>



    <context-param>

       
<param-name>contextConfigLocation</param-name>

        <param-value>

           
classpath:applicationContext.xml

        </param-value>

    </context-param>



    <listener>

       
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>


    </listener>



    <servlet>

       
<servlet-name>CXFServlet</servlet-name>

        <display-name>CXF
Servlet</display-name>

       
<servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>


       
<load-on-startup>1</load-on-startup>

    </servlet>



    <servlet-mapping>

       
<servlet-name>CXFServlet</servlet-name>

       
<url-pattern>/services/*</url-pattern>

    </servlet-mapping>

   

    <welcome-file-list>

       
<welcome-file>index.html</welcome-file>

    </welcome-file-list>

       

</web-app>

La première partie permet au contexte Spring d'être chargée grâce au ContextLoaderListener auquel on indique de charger le fichier applicationContext.xml.
On déclare ensuite la servlet CXF qui va permettre d'exposer nos services derrière le contexte helloworld-wss/services/.

e) compilation et packaging de l'application avec maven

Dans le pom.xml on ajoute le plugin pour compiler le tout en Java 6 :

<pluginManagement>

            <plugins>

               
<plugin>

               
   
<groupId>org.apache.maven.plugins</groupId>

               
   
<artifactId>maven-compiler-plugin</artifactId>

               
    <configuration>

               
        <source>1.6</source>

               
        <target>1.6</target>

               
    </configuration>

               
</plugin>

            </plugins>

</pluginManagement>

ensuite dans le répertoire du projet il suffit pour créer le WAR de lancer
$ mvn clean package
(ne pas oublier de mettre <packaging>war</packaging> en début du pom.xml)

f) déploiement

On peut utiliser le plugin maven pour tomcat, ou sinon voir cet article

g) utilisation du web service

Une fois la webapp déployée sous Tomcat, on peut aller à l'URL suivante http://localhost:8081/helloworld-wss/services/ pour voir ceci :

En cliquant sur le lien, on peut alors accéder au fichier WSDL qui aura l'allure suivante :

<?xml version='1.0' encoding='UTF-8'?><wsdl:definitions
name="HelloWorldWssImplService"
targetNamespace="http://wss.helloworld.openfarm.fr/"
xmlns:ns1="http://cxf.apache.org/bindings/xformat"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://wss.helloworld.openfarm.fr/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <wsdl:types>

<xs:schema elementFormDefault="unqualified"
targetNamespace="http://wss.helloworld.openfarm.fr/" version="1.0"
xmlns:tns="http://wss.helloworld.openfarm.fr/"
xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="sayHi" type="tns:sayHi" />

<xs:element name="sayHiResponse" type="tns:sayHiResponse" />

<xs:complexType name="sayHi">

    <xs:sequence>

      <xs:element minOccurs="0" name="text"
type="xs:string" />

    </xs:sequence>

  </xs:complexType>

<xs:complexType name="sayHiResponse">

    <xs:sequence>

      <xs:element minOccurs="0" name="return"
type="xs:string" />

    </xs:sequence>

  </xs:complexType>

</xs:schema>

  </wsdl:types>

  <wsdl:message name="sayHiResponse">

    <wsdl:part element="tns:sayHiResponse"
name="parameters">

    </wsdl:part>

  </wsdl:message>

  <wsdl:message name="sayHi">

    <wsdl:part element="tns:sayHi"
name="parameters">

    </wsdl:part>

  </wsdl:message>

  <wsdl:portType name="HelloWorldWss">

    <wsdl:operation name="sayHi">

      <wsdl:input message="tns:sayHi"
name="sayHi">

    </wsdl:input>

      <wsdl:output message="tns:sayHiResponse"
name="sayHiResponse">

    </wsdl:output>

    </wsdl:operation>

  </wsdl:portType>

  <wsdl:binding name="HelloWorldWssImplServiceSoapBinding"
type="tns:HelloWorldWss">

    <soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />

    <wsdl:operation name="sayHi">

      <soap:operation soapAction=""
style="document" />

      <wsdl:input name="sayHi">

        <soap:body use="literal"
/>

      </wsdl:input>

      <wsdl:output name="sayHiResponse">

        <soap:body use="literal"
/>

      </wsdl:output>

    </wsdl:operation>

  </wsdl:binding>

  <wsdl:service name="HelloWorldWssImplService">

    <wsdl:port
binding="tns:HelloWorldWssImplServiceSoapBinding"
name="HelloWorldWssImplPort">

      <soap:address
location="http://localhost:8081/helloworld-wss/services/HelloWorld" />

    </wsdl:port>

  </wsdl:service>

</wsdl:definitions>

La sécurisation fera l'objet d'un deuxième billet.
@Bientot

Activation des traces du driver JDBC Oracle

guillaume — Wed, 01 Sep 2010 18:03:00 +0200

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

Migration des scripts de démarrage de la Debian vers le LSB (Linux Standard Base)

guillaume — Tue, 24 Aug 2010 00:45:00 +0200

Récemment j'ai eu la surprise d'avoir cet écran lors d'une mise à jour Debian :

Il suffit de suivre les indications... Arf!

Voici les liens qui pourront vous permettre de réussir votre migration :

Dans mon cas la migration a été très simple :

un nettoyage des packages enlevés mais encore configuré avec dpkg --purge package pour enlever les fichiers de configuration (en vérifiant au préalable la liste des fichiers de configuration et s'il faut conserver quelque chose)
une mise à jour de mes scripts maison au format LSB
la reconfiguration de sysv-rc avec dpkg-reconfigure sysv-rc comme l'indique l'écran d'apt-get

Après ça votre Linux devrait être capable de lancer plusieurs scripts d'init à la fois en parallèle tout en respectant les dépendances entre scripts.

Expressions régulières ou regexp en java

guillaume — Tue, 24 Aug 2010 00:11:00 +0200

J'ai souvent cherché sur Internet des ressources claires et précises sur les expressions régulières en Java. En voici une qui a le mérite d'être claire, complète, avec des exemples et en français :
http://prevert.upmf-grenoble.fr/Prog/Java/CoursJava/expressionsRegulieres.html

Il y a bien sûr la documentation SUN (oops... Oracle) sur les regexp en java mais je la trouve illisible.

AVWorks , Java et IPv6

guillaume — Thu, 08 Jul 2010 13:18:00 +0200

L'application AVWorks est une application fournie avec les KVM IP d'Avocent et notamment la série des Autoview. Ces anciens KVM IP ne fonctionnent qu'en IPv4. AVWorks est réalisée en Java et il semblerait que la façon dont Sun ait implémenté la dual stack IPv4 / IPv6 dans la JVM est plutôt étrange ( cf. article suivant sur debian et ipv6 )... Surprise donc lorsqu'en passant en dual stack IPv4 / IPv6 sur Debian je me retrouve avec l'application AVWorks et toutes les autres applications java qui ne marchent plus.

J'ai donc cherché à patcher l'application afin qu'elle refonctionne et c'est possible. Voici comment faire :

surtout garder l'ancienne version 2.1 d'AVWorks et ne pas installer la nouvelle version 3.1 qui contient pas mal de bugs
dans le fichier AVWORKS_HOME/Avocent_AVWorks.lax il suffit d'y ajouter la variable d'environnement java "java.net.preferIPv4Stack=true" vers la ligne 68 comme ceci: lax.nl.java.option.additional=-Djava.library.path=AVWORKS_HOME/Avocent_AVWorks -Duser.variant=avct -Djava.net.preferIPv4Stack=true
(avec AVWORKS_HOME qui doit être remplacé par votre répertoire d'installation d'AVWorks)

Edit :
En fait, après enquête, il s'avère que le dysfonctionnement venait d'un problème plus général lié à la mise à jour de l'OS (i.e. une Debian)... Le paramètre noyau net.ipv6.bindv6only était à 1 !!! Ceci privilégie IPv6 avant tout, d'où les problèmes de java qui cherchait à se connecter en IPv6 avec des adresses IPv4. Pour remédier au problème il suffit de mettre net.ipv6.bindv6only=0 dans le fichier /etc/sysctl.d/bindv6only.conf et de lancer

invoke-rc.d
procps restart

pour faire appliquer la nouvelle configuration.

Sources :

sun-java6-jre: net.ipv6.bindv6only=1 breaks java networking

net.ipv6.bindv6only=1 breaks java networking

ERROR: transport error 202: connect failed: Connection refused

Chez Openfarm des architectes java certifiés Scrum Master

guillaume — Thu, 03 Jun 2010 10:01:00 +0200

Ils l'ont fait!

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

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

Maven comment créer un jar des sources

guillaume — Mon, 03 May 2010 18:29:00 +0200

Il peut arriver que l'on ait besoin de naviguer dans les sources d'un jar fait maison à travers Eclipse. Ce jar fait souvent d'un projet externe au projet courant, mais vous souhaitez pouvoir naviguer ou débugger dans ce code.

Il suffit d'ajouter ceci à votre pom.xml

<project>  ...

 <build>

    <plugins>

      <plugin>

        <groupId>org.apache.maven.plugins</groupId>

        <artifactId>maven-source-plugin</artifactId>

        <version>2.1.1</version>

        <executions>

          <execution>

            <id>attach-sources</id>

            <phase>verify</phase>

            <goals>

              <goal>jar-no-fork</goal>

            </goals>

          </execution>

        </executions>

      </plugin>

    </plugins>

  </build>

  ...

</project>

Ensuite la commande suivante fera l'affaire
$ mvn source:jar-no-fork

La solution se trouve en fait ici avec plus de détails : http://maven.apache.org/plugins/maven-source-plugin/usage.html

Maven optimiser le déploiement avec un WAR éclaté

guillaume — Mon, 03 May 2010 18:08:00 +0200

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

Au final vous avez plusieurs opérations couteuses en temps et en ressource. Tout doit être fait manuellement.

Comment accélérer le processus ?

Julien DUBOIS propose sur le blog de Responcia une solution intéressante pour optimiser vos développements avec Jetty. Il apporte la preuve en vidéo que l'on peut améliorer les productivité des développements Java de cette façon. Mais parfois, il n'est pas possible d'opter pour Jetty...

Packaging maven rapide

on package l'application avec la commande suivante

$ mvn -Dmaven.test.skip=true clean compiler:compile
war:exploded

-Dmaven.test.skip : saute l'exécution des tests
compiler:compile : compile le projets sans les tests (pour compiler aussi les tests ajouter compiler:testCompile et pour "tisser" l'AOP avec par exemple aspectj n'oubliez pas d'ajouter aspectj:compile !!!)
war:exploded (ou war:inplace) : ceci arrête le packaging de l'application au WAR éclaté (sans zipper l'arborescence éclatée dans un fichier WAR)

Script de déploiement rsync

La structure éclatée est ensuite déployée avec rsync. Si vous êtes sous Windows utilisez Cygwin et lancez votre script avec >sh monScript.sh.
J'utilise tomcat avec une structure multi-instance avec un déploiement par fichier de contexte XML à placer généralement dans le répertoire conf/Catalina/localhost
Un script s'impose (à adapter et améliorer en fonction des besoins).

Sous linux :

#!/bin/sh

JSERVER_USER=tomcat

HOST_DEPLOY=monserveur.mondomain.com

proj_name=monprojet

PROJ_HOME=~/workspace/$proj_name/target/$proj_name

TC_HOME=/srv/tomcat6

TC_INSTANCE=instance_monprojet

ssh ${JSERVER_USER}@${HOST_DEPLOY} "JAVA_HOME=/srv/java/jdk
${TC_HOME}/${TC_INSTANCE}/bin/catalina.sh stop"

mvn -Dmaven.test.skip=true clean compiler:compile war:exploded

time rsync -rzvt -e ssh --delete --progress ${PROJ_HOME}/*
tomcat@${HOST_DEPLOY}:${TC_HOME}/webapps/$proj_name/

ssh ${JSERVER_USER}@${HOST_DEPLOY} "JAVA_HOME=/srv/java/jdk
${TC_HOME}/${TC_INSTANCE}/bin/catalina.sh start"

Evidemment, il faudra copier sa clé publique SSH dans /home/tomcat/.ssh/authorized_keys pour que les commandes d'arrêt et de démarrage du serveur Tomcat soient exécutées de façon transparente sans avoir à entrer les mots de passe à chaque fois. La commande ssh-copy-id (du moins sous Debian) est appropriée. Sinon faire la copie à la main de votre clé publique dans l'authorized_keys du serveur.

Sous windows, si votre disque est par exemple D:,remplacez la ligne PROJ_HOME par
PROJ_HOME=/cygdrive/d/workspace/$proj_name/target/$proj_name

Que fait ce script de déploiement ?

il arrête le serveur d'application distant grâce à SSH
il compile et package l'appli avec Maven (sur le poste de développement)
il synchronise l'arborescence éclatée avec l'arborescence distante de l'application; l'option --delete de rsync est importante car elle permet d'éliminer les fichiers sur le serveur distant qui ont pu être supprimés lors des modifications précédentes sur le code (suppressions de classe, de librairie etc.)
il redémarre le serveur d'application

Cette méthode présente plusieurs avantages :

si vous êtes derrière une ligne ADSL pour déployer vers un serveur distant, vous gagnerez un temps précieux pour uploader votre application (upload parfois 100 fois supérieur puisque rsync ne transfère que les modifications entre fichiers); en effet, vos librairies JAR ne changent pas beaucoup une fois le projet initié et rsync verra qu'il n'y a pas besoin de les redéployer... évidemment pour chaque nouveau fichier, le premier upload sera coûteux...
le déploiement est propre car ceci arrête le serveur avant le déploiement; le déploiement à chaud sur Tomcat entraîne généralement le bien connu "OutOfMemoryError : PermGen Space"; certains diront que cette erreur peut être évitée ( http://jroller.com/agileanswers/entry/preventing_java_s_java_lang ) mais parfois, on a pas le choix...
les tâches sont toutes automatisées et le temps de déploiement est sérieusement optimisé : -30% sur le packaging (x5 s'il n'y a pas à faire de clean sur le projet), x10 à x100 sur le déploiement et votre serveur n'a pas besoin de dézipper le WAR (en prime vous gagnez de l'espace puisque vous n'avez plus de WAR sur le serveur cible)...
le scripting apporte une flexibilité accrue notamment si vous avez à déployer sur plusieurs instances et/ou serveurs à la fois dans le cadre d'un cluster. Les options rsync permettent aussi d'exclure des fichiers que vous ne voulez pas ou plus déployer, mais attention : ceci peut être dangereux pour votre application si vous excluez des fichiers et que vous oubliez ensuite qu'il faille les déployer de nouveau...

Conclusion

Dans cet exemple le déploiement est fait directement entre le poste de développement et le serveur. Il se peut qu'en entreprise lorsque vous travaillez à plusieurs sur le serveur distant, que ce dernier ait accès à un repository Subversion ou GIT. Dans ce cas il suffit d'adapter le script pour qu'il se trouve sur le serveur et que ce soit lui qui récupère des sources par SVN (qui fonctionne par différence tout comme rsync!). Le script récupère alors les sources, construit le projet, arrête le serveur d'appli (ou l'application), déploie, redémarre le serveur d'appli (ou l'application).
Si l'on est dans un process d'intégration continue, on peut par exemple utiliser Hudson auquel on fournira un script shell réduit au déploiement (installer un plugin d'opération post-build), le build étant gérée par Hudson en lui fournissant les options maven.

Pour plus d'infos : http://maven.apache.org/plugins/maven-war-plugin/

Comment mettre à jour une vieille Debian Sarge ?

guillaume — Tue, 06 Apr 2010 16:53:00 +0200

Souvent, lorsque ça marche bien, on ne touche à rien... Et puis le temps passe, et la distribution Debian vieillit...

Pour pouvoir mettre à jour une sarge il faut mettre comme nom de repository archive.debian.org au lieu de ftp.debian.org
(pour security je ne sais pas)

Oracle native JDBC connection extractor

guillaume — Thu, 01 Apr 2010 20:00:00 +0200

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.

Extraction d'une connexion native JDBC

1) avec Spring

Ceux qui utilisent Spring connaissent probablement le package org.springframework.jdbc.support.nativejdbc qui contient des extracteurs de connexion.
Voici par exemple comment récupérer une connexion native sous-jacente avec un extracteur Spring :

import javax.sql.DataSource;

import java.sql.Connection;

import org.springframework.jdbc.datasource.DataSourceUtils;

import
org.springframework.jdbc.support.nativejdbc.SimpleNativeJdbcExtractor;



DataSource dataSource = ... // récupération par JNDI par exemple et/ou injecté
par Spring

Connection conn = DataSourceUtils.getConnection(dataSource);

SimpleNativeJdbcExtractor extractor = new SimpleNativeJdbcExtractor();

OracleConnection oraConn = (OracleConnection)
extractor.getNativeConnection(conn);

Généralement les applications conçues avec Spring gère généralement les ressources base de données à haut niveau (niveau DataSource). La classe utilitaire DataSourceUtils de Spring permet notamment de récupérer la connexion sous-jacente à la DataSource. Ensuite, le SimpleNativeJdbcExtractor permet d'extraire la connexion native en réalisant un unwrap de la connexion du pool. D'autres extracteurs existent dans ce package utilitaire de Spring, mais malheureusement, cela ne fonctionne pas toujours.

2) sans Spring

En effet, si vous avez un pool de connexion fait maison il sera alors beaucoup plus difficile d'utiliser les classes utilitaires Spring. Un autre cas de figure est lorsque l'application doit pouvoir être déployée sur différents conteneurs JEE, dont certains non identifiés par les outils Spring.
Dans certains cas, la méthode getMetadata() de l'objet Connection peut-être utilisé directement pour récupérer la connexions native. Dans d'autres cas, il faut utiliser la méthode getUnderlyingConnection() (pas toujours présente) pour récupérer la connexion native (comme c'est le cas pour le wrapper JBoss).
Voici la classe utilitaire permettant de récupérer une connexion native Oracle quelque soit le conteneur (pas testé partout) :

package com.openfarm.util; import java.lang.reflect.Method; import java.sql.Connection; import java.sql.SQLException; import oracle.jdbc.OracleConnection; import org.apache.log4j.Logger; /** * Classe statique réalisant quasiment la même chose que la classe spring suivante * org.springframework.jdbc.support.nativejdbc.SimpleNativeJdbcExtractor * c'est à dire extraire la connection native sous-jacente d'un pool de connexion. * La récupération à travers les metadata fonctionne avec la plupart des pools de * connexion (JBoss 3.x, DBCP 1.x, Resin, etc.) * La récupération de la connexion native est parfois nécessaire notamment pour * l'utilisation de l'API Network Data Model d'Oracle. * * @author guillaume viel at openfarm dot fr * */ public class OracleNativeJdbcExtractor { private static final Logger logger = Logger.getLogger(OracleNativeJdbcExtractor.class); /** * Retourne la connexion native sous-jacente au pool de connexion * @param poolConn La connexion du pool * @return Connection La connexion native * @throws SQLException */ public static Connection getNativeConnection(Connection poolConn) throws SQLException { Connection nativeConn = poolConn; if(poolConn != null) { nativeConn = poolConn.getMetaData().getConnection(); logger.info(poolConn + " encapsulates ["+nativeConn+"]"); } return nativeConn; } /** * Retourne la connexion native Oracle sous-jacente au pool de connexion * @param poolConn La connexion du pool * @return OracleConnection La connexion Oracle sous-jacente au pool * @throws SQLException */ public static OracleConnection getNativeOracleConnection(Connection poolConn) throws SQLException { OracleConnection oraConn = null; if(poolConn != null) { logger.debug( poolConn.getClass().getName() ); // permet d'identifier le nom du wrapper try { oraConn = (OracleConnection)poolConn.getMetaData().getConnection(); logger.info(poolConn + " wraps [" + oraConn + "]"); } catch(ClassCastException e) { // fonctionne par exemple avec le wrapper JBoss qui supporte la methode getUnderlyingConnection try { Method method = poolConn.getClass().getDeclaredMethod("getUnderlyingConnection", (Class[])null); if(method != null) { oraConn = (OracleConnection)method.invoke(poolConn, (Object[])null); logger.info(poolConn + " encapsulates ["+oraConn+"]"); } } catch (Exception e1) { e1.printStackTrace(); } } } return oraConn; } }

ORA-04061 ô désespoir, ô variable ennemie

guillaume — Tue, 30 Mar 2010 15:59:00 +0200

Que signifie l'exception ORACLE ORA-04061 ?

Souhaitant rationaliser un projet de plusieurs milliers de lignes de PL/SQL, j'ai rencontré cette exception lorsque nous avons mis en package les procédures et fonctions. L'exception se présente comme suit :

ORA-04061: existing state of package "SCHEMA_REF.MON_PACKAGE" has been invalidated ORA-04065: not executed, altered or dropped package "SCHEMA_REF.MON_PACKAGE" ORA-06508: PL/SQL: could not find program unit being called: "SCHEMA_REF.MON_PACKAGE" ORA-04088: error during execution of trigger 'MON_SCHEMA.MON_TRIGGER'

L'erreur est déroutante au premier abord car le package MON_PACKAGE, une fois compilé, est tout à fait valide et il n 'y a a priori aucune erreur à la compilation d'après ORACLE. Ce n'est qu'à la deuxième exécution (par un tiers) que les problèmes surviennent. Alors que se passe-t-il exactement?

Les packages peuvent être invalidés pour plusieurs raisons :

lorsque la spécification d'un package (une "spéc" de package correspond à une interface en java) dont ils dépendent change ou a été supprimée
lorsque la spécification du package dépend d'une table qui a été modifiée ou supprimée
lorsqu'il contient des variables globales de package
lorsqu'il contient des exceptions au niveau du package

Il est donc dangereux en production de modifier des spécifications de package, à moins de pouvoir recompiler en masse tous les packages impliqués. Cela peut suffire pour les 2 premières causes d'invalidation du package. Mais les deux dernières causes sont plus problématiques.

Voici les spécs de notre package avec notamment une constante, une variable globale et une exception.

CREATE OR REPLACE PACKAGE SCHEMA_REF.MON_PACKAGE AS -- RAD_TO_DEG CONSTANT NUMBER := 180 / ( ATAN(1) * 4 ); MA_VARIABLE_GLOBALE NUMBER := 0; EXCEPTION e_mon_exception; -- FUNCTION MA_FONCTION_RIGHT(vString VARCHAR2, vLength NUMBER) RETURN VARCHAR2; PROCEDURE MA_PROC(); END;

Cette spécification de package provoquera immanquablement l'erreur ORA-04061 car les variables et constantes au niveau package font partie de l'ETAT du package. Si cet état change, comme par exemple la modification de la valeur de MA_VARIABLE_GLOBALE par une procédure ou fonction, Oracle considère que les spécifications du package sont changées! Ce qui est normal car si 2 utilisateurs créent 2 sessions en parallèle : on a une concurrence potentielle au niveau des variables d'état du package. Oracle met alors le package en statut invalide.
Le problème est le même pour les exceptions qui sont en fait des objets potentiellement modifiables au cours de la session d'un utilisateur, provoquant ainsi l'invalidation d'un package.

Pour mieux structurer un projet PL/SQL, la seule option est de placer toutes les constantes dans un package ne contenant que des spécifications de constantes. Il est impossible d'isoler et regrouper les exceptions dans un package de spécifications, ni dans l'entête d'un package : toutes les exceptions doivent être gérées à l'intérieur des fonctions et procédures, ce qui représente un travail d'uniformisation et normalisation important. C'est un point faible pour maintenir convenablement des applications PL/SQL.

Ces deux articles expliquent bien le problème (mis à part qu'il ne parlent pas du cas des EXCEPTION) :

http://kr.forums.oracle.com/forums/thread.jspa?threadID=903490

http://oraclequirks.blogspot.com/2007/03/ora-04061-existing-state-of-package-has.html

Ce dernier article explique comment recompiler en masse ou programmatiquement des objets dans Oracle :

http://www.oracle-base.com/articles/misc/RecompilingInvalidSchemaObjects.php

FreeNAS Cannot dump. No dump device defined

guillaume — Sat, 27 Mar 2010 15:47:00 +0100

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?

Le premier élément de réponse est le suivant :

hint.acpi.0.disabled="1"

serait à mettre dans le fichier /cf/boot/loader.conf
Qu'à cela ne tienne, me voilà déjà parti pour modifier le fameux fichier... mais...

/cf/boot/loader.conf: Read-only file system.

Eh oui! La carte flash est montée en read-only comme le montre la fstab



freenas:~# cat /etc/fstab

/dev/ad4a /cf ufs ro 1 1

Il suffit donc de :

remonter la partition en rw avec mount :
mount -u -o rw /dev/ad4a /cf
dans /cf/boot/loader.conf ajouter la ligne
hint.acpi.0.disabled="1"
rebooter pour vérifier que tout est OK

Normalement, le serveur devrait booter correctement sans aucune intervention manuelle pour désactiver l'ACPI.

FreeNAS versions 0.7 et 0.7.1 : impossible de monter un volume NFS

guillaume — Fri, 26 Mar 2010 23:15:00 +0100

Décidément, pas de chance en ce moment... Cascade de bugs... Faut dire que je le cherche un peu, en étant sous Debian SID. Mais là, c'est pas Debian! Nous avons mis à jour notre serveur NAS avec la dernière version de FreeNAS et apparemment quelques soucis sur les montages NFS. En effet, une tentative de connexion donne le message suivant :

mount.nfs: mount to NFS server failed: timed out, giving up

Yuk! Après avoir vérifié le ping, que tous les ports étaient ouverts, une petite trace avec wireshark m'a permis de constater qu'un échange avait bien lieu mais que la connexion entre le client et le serveur n'aboutissait pas. Et il semblerait que je ne sois pas le seul à avoir ce problème vu ce bug sur le bug tracker de FreeNAS

http://sourceforge.net/tracker/?func=detail&aid=2812161&group_id=151951&atid=782616

La meilleure parade est de revenir à la version 0.69.2 en attendant mieux.

rsnapshot : module Lchown manquant

guillaume — Thu, 25 Mar 2010 23:37:00 +0100

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 :

require Lchown

Lchown module not found

En fait il manque tout simplement le module PERL Lchown (avec il manque YAML)!

Pour l'importer, taper ceci (connexion internet obligatoire) :

perl -MCPAN -e 'install qw(YAML)'

perl -MCPAN -e 'install qw(Lchown)'

Une fois ces librairies PERL installées, rsnapshot ne se plaint plus sur les chown.

linux debian squeeze : bug sur la configuration PAM pour CRON

guillaume — Thu, 25 Mar 2010 00:37:00 +0100

La programmation de tâches par CRON peut se faire de différentes façon, et notamment par l'intermédiaire de fichiers de configuration situés dans /etc/cron.d

En voulant programmer des tâches de sauvegarde rsnapshot avec cron, je constate l'erreur suivante dans mon /var/log/syslog

Mar 24 23:04:01 myhost CRON[8435]: Erreur critique - abandon immédiat
Mar 24 23:04:01 myhost CRON[8435]: PAM pam_end: NULL pam handle passed

ou pour la version originale

Mar 24 23:04:01 myhost CRON[8435]: Critical error - immediate abort
Mar 24 23:04:01 myhost CRON[8435]: PAM pam_end: NULL pam handle passed

Que se passe-t-il ?

Le problème vient de la configuration de la librairie PAM qui sert d'interface entre les applications et le système pour la gestion des authentifications / autorisations.

Mais celui ne correspond pas à ce que j'ai dans ma debian squeeze. Voici le contenu du fichier /etc/pam.d/cron :

# # The PAM configuration file for the cron daemon # @include common-auth session required pam_env.so @include common-account @include common-session-noninteractive # Sets up user limits, please define limits for cron tasks # through /etc/security/limits.conf session required pam_limits.so

En analysant chaque ligne d'@include qui correspond à l‘inclusion d'un fichier dans /etc/pam.d on constate que le fichier /etc/pam.d/common-session-noninteractive n'existe pas! Seul le fichier common-session est présent. J'ai donc remplacé comme suit et tout fonctionne :

@include common-session

Je ne sais pas si c'est la bonne solution, mais ça a le mérite de refaire fonctionner cron!

Le rapport de bug est ici :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575342

Configuration d'un pool de connexions JDBC avec Oracle RAC

guillaume — Wed, 24 Mar 2010 18:37:00 +0100

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 :

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.

Git : un SCM (Source Code Management) qui vaut le détour

guillaume — Mon, 15 Mar 2010 14:39:00 +0100

Un peu déçu par SVN, nous nous sommes mis à la recherche d'un nouveau système SCM ou de Gestion de Version . Notre futur SCM sera très probablement GIT. L'article suivant permet de bien débuter sur GIT : http://www.unixgarden.com/index.php/administration-systeme/git-it

Comment changer une extension de fichier en bash (utilisation des substitutions en bash)

guillaume — Mon, 15 Mar 2010 14:31:00 +0100

Pour éviter des sed dans tous les sens, on oublie souvent les substitutions qui couvrent un majorité des besoins pour traiter les noms de fichier :
http://djmathos2.free.fr/joomla/index.php/astuceslinux/67-changer-lextension-dun-fichier-en-shell-bash