Administrateur & Développeur système UNIX/Linux

Toi prendre ta pelle & ton sceau avec comme point de rendez-vous :

http://code.google.com/apis/ajax/playground/

Un petit bout de code utile pour tout programme de type démon/serveur et qui permet d’enregistrer dans un fichier journal (cf. API java.util.logging) toute exception non gérée, en particulier avec son stacktrace complet, tel que Java le produirait en console :

private final static Logger m_logger = Logger.getLogger ("package.MyClass");

try
{
    [...]
}
catch (Exception exception)
{          
    StringBuilder stackTrace = new StringBuilder ("exception during execution: " +
        exception.getMessage ());

    for (StackTraceElement element : exception.getStackTrace ())
    {           
        stackTrace.append ("\n\tat " + element.getClassName ()
                + ":" + element.getMethodName () + "("
                + element.getFileName () + ":"
                + element.getLineNumber () + ")");
    }

    m_logger.log (Level.SEVERE, stackTrace.toString ());
}

Exemple d’output :

2 mai 2009 18:51:26 fr.hbis.ircs.Client parse
GRAVE: exception during command execution 'JOIN': fr.hbis.ircs.Channel.create(Ljava/lang/String;
    Ljava/lang/String;)Lfr/hbis/ircs/Channel;
    at fr.hbis.ircs.commands.Join:doCommand(Join.java:130)
    at fr.hbis.ircs.commands.Join:execute(Join.java:64)
    at fr.hbis.ircs.Client:parse(Client.java:158)
    at fr.hbis.ircs.Client:read(Client.java:127)
    at fr.hbis.ircs.nio.MessageTask:doProcess(MessageTask.java:253)
    at fr.hbis.ircs.nio.MessageTask:doRead(MessageTask.java:197)
    at fr.hbis.ircs.nio.MessageTask:doTask(MessageTask.java:152)
    at fr.hbis.ircs.lib.nio.task.TaskBase:run(TaskBase.java:102)
    at java.util.concurrent.ThreadPoolExecutor$Worker:runTask(ThreadPoolExecutor.java:885)
    at java.util.concurrent.ThreadPoolExecutor$Worker:run(ThreadPoolExecutor.java:907)
    at fr.hbis.ircs.lib.nio.worker.DefaultWorkerThread:run(DefaultWorkerThread.java:123)

Sympa, on en perd plus une miette.

Un petit pense-bête concernant les différentes options d’exécution de la JVM étant donné que j’arrive pas les retenir.

Journalisation avec fichier de configuration custom pour l’API java.util.logging :

java [...] -Djava.util.logging.config.file=./logging.properties [...]

Monitoring avec jconsole :

en local :

java [...] -Dcom.sun.management.jmxremote [...]

à distance :

java [...] -Dcom.sun.management.jmxremote \
        -Dcom.sun.management.jmxremote.port=8001 \
        -Dcom.sun.management.jmxremote.authenticate=false \
        -Dcom.sun.management.jmxremote.ssl=false [...]

Remote debug JDPA :

avec JVM < 5.0 :

java [...] -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address="8000" [...]

avec JVM >= 5.0 :

java [...] -agentlib:jdwp=transport=dt_socket,server=y,address="8000" [...]

Parfois, il est indispensable de tester son application sous un environnement précis. Si cela ne tourne pas rond, un debug est nécessaire. Pour conserver les mêmes conditions d’exécution, un debug distant depuis son IDE est possible. Le principe est qu’une connexion réseau est faite entre le frontend du débogueur (IDE) et un backend au niveau de la JVM (JDPA, Java Debug Architecture). Deux méthodes sont possibles  :

• « Socket attach » : une socket est en écoute au niveau de la JVM. L’IDE va s’y connecter pour contrôler le flux d’exécution et récupérer les informations de debug.
• « Socket listen » : une socket est en écoute sur la machine de développement. Dans ce cas, la JVM s’y connecte pour ensuite être contrôlée.

Le choix entre les 2 méthodes dépend du filtrage réseau présent entre les 2 postes. Des options spécifiques sont donc à fournir à la JVM dont l’adresse IP / port de la socket et la méthode de remote debug.

Avec Eclipse, un remote debug par socket attach se fait ainsi :

1. Compilation des sources avec les options de debug (sans blague)
2. Déploiement / lancement de l’application sur la machine de test :
   

   java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000 [...]

3. Lancer l’application depuis l’IDE avec une configuration de remote debug en précisant l’IP + port du serveur d’exécution : menu Run -> Debug … -> Remote Java Application.

Le reste s’effectue comme un debug traditionnel.

Screenshot 1 : lancement de la JVM d’exécution avec backend JDPA
Screenshot 2 : configuration debug avec l’IP/port du serveur d’exécution
Screenshot 3 : session de debug distante

Un package binaire de Git pour Mac OS X est disponible à cet adresse :

http://code.google.com/p/git-osx-installer/downloads/list?can=3

Une collection de mémentos à garder sous la main.

La prochaine version 3.5 d’Eclipse apportera le portage de la librairie graphique SWT sous Cocoa (Mac OS X 10.5 uniquement).

Pour tester une version de développement, cliquez ici.