P³ A new story begins

Voici la liste de plugins que j'utilise avec Hudson

1. Hudson Active Directory plugin
2. Analysis Collector Plugin
3. Static Code Analysis Plug-ins
4. Backup Plugin
5. Checkstyle Plugin
6. ChuckNorris Plugin
7. Hudson Continuous Integration game
8. Dashboard View
9. Hudson Dependency Analyzer Plugin
10. Deploy Plugin
11. Hudson disk-usage plugin
12. DRY Plugin
13. Hudson Email Extension Plugin
14. Emotional Hudson plugin
15. FindBugs Plugin
16. FTP publisher plugin
17. Green Balls
18. Hudson JavaNCSS plugin
19. Hudson Maven Release Plug-in Plug-in
20. Hudson Mantis plugin
21. Maven 2 Project Plugin
22. Monitoring
23. PMD Plugin
24. Hudson Support Subscription Notification Plugin
25. SCP plugin
26. Hudson Sonar Plugin
27. Hudson SSH Slaves plugin
28. Subversion Plugin
29. Task Scanner Plugin
30. Translation Assistance Plugin
31. Hudson Violations plugin
32. Warnings Plugin

Un petit billet sous forme de memento:

Voici les paramètres essentiels pour la machine virtuelle Java d'un Tomcat de dévelopement ou d'intégration : (avec une JVM SUN)

///

Arguments to pass to the Java virtual machine (JVM).

JAVA_OPTS="-Xms64m -Xmx512m -XX:PermSize=32m -XX:MaxPermSize=256m -XX:+CMSClassUnloadingEnabled -Djava.awt.headless=true -Xdebug -Xrunjdwp:transport=dt_socket, address=8000,server=y,suspend=n -Dcom.sun.management.jmxremote"

///

1. -Xms64m
2. -Xmx512m : application quelque peu gourmande en mémoire.
3. -XX:PermSize=32m
4. -XX:MaxPermSize=256m : Utilisation massive de spring-hibernate avec des proxies donc le perm gen est bien utilisé
5. -XX:+CMSClassUnloadingEnabled : essaye de décharger les classes de l'espace permanent generation
6. -Djava.awt.headless=true (gestion sans IHM pour permettre les impression des graphiques pe: pour lambdaprobe)
7. -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
8. -Dcom.sun.management.jmxremote : utilisation du débugger d'eclipse à distance

Mais pourquoi utiliser Sonar ??

Tout simplement parce que la qualité ne dépend pas des développeurs mais des priorités du moment.

Voici un exemple pour une petite application développé par un seul développeur (en l'occurrence c'est moi qui m'y suis collé)

Avant le premier commit, revue de code et Hop un bon 99%

Puis dans l'urgence modification du code pour ajouter des fonctionnalités non prévues et bam ... le nombre de lignes a bien augmenté mais la qualité a baissée (pas tant que ça au vue des 50% de code en plus).

D'où la nécessité de refaire une revue de code et là miracle on arrive aux 100% !!

Pour ce projet un seul développeur était à l'œuvre imaginez avec plusieurs dont des débutants modifiant le code d'expérimentés ...

La qualité c'est bien mais la suivre en temps réel c'est mieux

Une belle page comme celle-là ca se mérite :D

et encore il reste des corrections, 2 lignes de codes commentées et 2copier-coller qui auraient pu être factorisé... il reste toujours du travail quand on est perfectionniste :p

Un petit billet au sujet de la gestion des logs avec Java :

Si on se réfère au règles diverses (Checkstyle, PMD ...), voici la bonne façon de déclarer un logger en Java

// Pour Log4J avec commons-logging
private static final Log logger = LogFactory.getLog(MyClass.class);
 
// Pour logback avec slf4j
private static final Logger logger = LoggerFactory.getLogger(MyClass.class);

...Hein.. c'est quoi logback ???

Logback est le digne hériter de log4j, il a été conçu en même que les api slf4j par le créateur lui même de log4j: Ceki Gülcü

Il y a de nombreuses raisons d'utiliser logback, et elles sont toutes expliquées sur le site http://logback.qos.ch/reasonsToSwitch.html

Le seul défaut est que vous perdrez le niveau fatal, mais bon toutes les erreurs ne devraient-elles pas êtres évitées, et un niveau fatal devraient entrainer l'arrêt de l'application ??

Donc switchons tous ensemble :D

Revenons à nos moutons si on veut logger des évènements qui ont lieu dans une classe abstraite commune la bonne solution est de déclarer le logger protégé et de l'initialiser de manière statique.

protected transient final Logger logger = LoggerFactory.getLogger(this.getClass());

Toutefois cette déclaration n'est pas compatible avec une règle (qui à dit 'à la con') de PMD à savoir LoggerIsNotStaticFinal

Certains puristes veulent que la classe Abstraite et la classe fille ai chacune leur propre logger pour permettre de les filtrés différemment avec le fichier de configuration du gestionnaire de log. (cf ce billet )

Personnellement j'ai jamais voulu séparer les logs des méthodes abstraites hérités de celles déclarées dans la classe fille, surtout quand la pile d'appel est imbriqué et que plusieurs classes filles peuvent être appelés.

On pourrait ajouter l'information getClass() dans chaque log de la classe abstraite, mais c'est quand même relativement pénible

Donc comment faire ??

Une des solutions peut-être d'utiliser AOP => en bon français la Programmation par aspect (soit en bon anglais Aspect Oriented Programmation à opposer à la OOP)

Avec Spring AOP par exemple on peut ajouter des logs sur des points de coupe définissant des endroits où logger.

Voici la déclaration via le conteneur léger de spring (spring-beans):

<bean id="loggingAdvice" class="fr.webeo.rapidoo.aop.LoggingAdvice" />
 
<bean id="loggingAdvisor" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
	<property name="advice" ref="loggingAdvice" />
	<property name="pattern" value="fr.webeo.rapidoo.services" />
	<property name="order" value="50" />
</bean>

A vous de spécialiser votre point de coupe si vous voulez plus de précision, ici toutes les méthodes de toutes les classes du package fr.webeo.rapidoo.services seront traitées à la même enseigne !

Et l'advice qui va logger tout seul les classes filles

public class LoggingAdvice implements MethodBeforeAdvice, AfterReturningAdvice, ThrowsAdvice {
 
    /**
     * Default Constructor.
     */
    public LoggingAdvice() {
        // Nothing to do
    }
 
    /**
     * {@inheritDoc}
     */
    @Override
    public void before(final Method method, final Object[] args, final Object target) throws Throwable {
        final Logger logger = LoggerFactory.getLogger(target.getClass());
        if (logger.isInfoEnabled()) {
            logger.info("Calling : " + method.getName() + " " + target.getClass().getName());
        }
        if (logger.isDebugEnabled()) {
            final StringBuilder sb = new StringBuilder();
            sb.append("Parameters : ");
            if (method.getParameterTypes().length == args.length) {
                for (int i = 0; i < args.length; i++) {
                    sb.append("\r\nParam : ").append(method.getParameterTypes()[i]).append(" - ").append(args[i] == null ? "null" : args[i].toString());
                }
            }
            if (sb.length() > 1000) {
                logger.debug(sb.substring(0, 1000));
            } else {
                logger.debug(sb.toString());
            }
        }
    }
 
    /**
     * {@inheritDoc}
     */
    @Override
    public void afterReturning(final Object returnValue, final Method method, final Object[] args, final Object target) throws Throwable {
        final Logger logger = LoggerFactory.getLogger(target.getClass());
 
        if (logger.isInfoEnabled()) {
            logger.info("Returning : " + method.getName());
        }
        if (logger.isDebugEnabled() && returnValue != null) {
            if (returnValue instanceof List) {
                logger.debug("Return value is list of " + ((List<?>) returnValue).size() + " elements.");
            } else {
                logger.debug("Return Value = " + returnValue.toString());
            }
        }
    }
 
    /**
     * Call after an exception thrown.
     * 
     * @param method the method called
     * @param args the method arguments
     * @param target the object who call the method
     * @param exception the exception thrown
     */
    public void afterThrowing(final Method method, final Object[] args, final Object target, final Throwable exception) {
        final Logger logger = LoggerFactory.getLogger(target.getClass());
        if (logger.isErrorEnabled()) {
            logger.error("Throwing : " + method.getName() + " \r\n=> " + exception.getMessage(), exception);
        }
    }
}

Pour conclure il existe 3 possibilités pour logger des classes filles héritant d'une même classe abstraite :

• Un logger par classe

Avantages : Chaque ligne de la log renvoi vers la bonne classe physique

Défauts : les log contiendront des log par enfant et pour la classe mère, donc si quelque chose se passe mal dans la classe abstraite il faut espérer trouver à proximité une log indiquant quel est la classe fille concernée (ou bien la rajouter explicitement dans la ligne loggée)

• Déclaration du logger de la classe abstraite en protected non static

Avantages : Toutes les logs seront générés au nom de la classe fille

Défauts : les numéros de lignes des méthodes héritées concerneront la classe abstraite

• Déclaration des loggers via AOP :

Avantages : Déclaration très rapide, bonne personnalisation

Defauts : Seulement utile pour les log génériques, induit donc une bonne conception objet avec des méthodes courtes et atomiques
Et vous comment faîtes-vous ??

Tout récemment j'ai été confronté à un problème comment lancer des tests se services java effectuant des requêtes en base de données avec une datasource JNDI !!!

Une des solution aurait été de se connecter directement à la base de données avec une URL standard, mais je ne souhaitait pas modifier le code existant.

Donc voici l'astuce :

System.setProperty(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory");
InitialContext context = new InitialContext();
 
Reference reference = new Reference("javax.sql.DataSource", "org.apache.commons.dbcp.BasicDataSourceFactory", null);
reference.add(new StringRefAddr("driverClassName", "oracle.jdbc.OracleDriver")); //Le driver de la base utilisée
reference.add(new StringRefAddr("url", "url_de_la_base"));
reference.add(new StringRefAddr("username", "username"));
reference.add(new StringRefAddr("password", "password"));
context.rebind("jdbc/myappl", reference);

Nous n'avez plus qu'à renseigner le user/mot de passe et l'url de la base, bien sur si vous n'utilisez pas une base oracle changez le driver et n'oubliez pas le driver jdbc

Pour pouvoir utiliser ce code vous aurez besoin de rajouter les jars suivant dans votre classpath :

• fscontext.jar
• providerutil.jar
• commons-dbcp-1.4.jar (pour la factory de Datasource)

Les deux premiers jars sont récupérable chez Sun/Oracle

POur vous faire gagner du temps les voici réunit dans une archive : Jars pour utiliser une datasource via JNDI

Voici une liste intéressante de plugin maven utiles pour le reporting et la génération du site.

<reporting>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-pmd-plugin</artifactId>
        <configuration>
          <targetJdk>1.5</targetJdk>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-checkstyle-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-plugin-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jxr-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-javadoc-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>taglist-maven-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>changelog-maven-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-project-info-reports-plugin</artifactId>
        <version>2.1.2</version>
        <reportSets>
          <reportSet>
            <reports>
              <report>summary</report>
              <report>project-team</report>
              <report>mailing-list</report>
              <report>cim</report>
              <report>issue-tracking</report>
              <report>license</report>
              <report>scm</report>
            </reports>
          </reportSet>
        </reportSets>
      </plugin>
    </plugins>
  </reporting>

Voici le contenu du code source d'un fichier exemple ou une Map est déclaré :

Voici une petite capture de l'éditeur ecore d'Eclipse pour plus de clarté :

Et le code du fichier ecore pour plus d'exhaustivité...

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="fr">
  <eSubpackages name="webeo">
    <eSubpackages name="blog">
      <eClassifiers xsi:type="ecore:EClass" name="CarOwner">
        <eStructuralFeatures xsi:type="ecore:EReference" name="carMap" upperBound="-1"
            eType="#//webeo/blog/CarMapEntry" containment="true"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Car"/>
      <eClassifiers xsi:type="ecore:EClass" name="CarMapEntry" instanceClassName="java.util.Map$Entry">
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="key" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="value" lowerBound="1"
            eType="#//webeo/blog/Car" containment="true"/>
      </eClassifiers>
    </eSubpackages>
  </eSubpackages>
</ecore:EPackage>

Et pour terminer le fichier ecore :D

Fichier Ecore avec Gestion de Map