-
JRebel avec OpenJDK et Grizzly
Grâce au ParisJUG,j’ai pu obtenir une licence JRebel. JRebel est censé faire gagner du temps aux développeurs en leur évitant de redémarrer leur application ou serveur d’applications après chaque changement. Selon le serveur d’applications, le redéploiement à chaud peut répondre partiellement à ce besoin, mais JRebel semble aller plus loin, en rechargeant les classes au niveau de la JVM.
Dans un projet récent, j’ai eu à travailler avec Grizzly, OpenJDK et Jersey pour développer des services RESTful, et j’ai compris l’intérêt que pouvait avoir ce type d’outil car, en phase d’évaluation de la plateforme, je fais beaucoup de petites modifications dont je veux voir immédiatement l’effet. Si redémarrer Grizzly est très rapide, cela demande des clics à des endroits différents dans l’IDE, Eclipse en l’occurrence. J’ai donc décider d’inclure JRebel dans cet environnement.
-
Silverpeas sur JBoss 5
Dans mon billet précédent, j’avais installé Silverpeas v5 dans JBoss 4, sur une machine Debian 5. Je vais maintenant m’attaquer à l’installation de Silverpeas v5 dans JBoss 5, sur la même machine. Ce n’est toujours pas mon but ultime, mais comme je connais bien ce serveur d’applications, je continue ainsi à me faire la main. Tout d’abord, je dois noter que je n’ai aucune garantie de réussite et que je devrai probablement faire des modifications à la configuration de Silverpeas pour l’adapter aux contraintes de cette version de JBoss.
Comme il n’y a pas de procédure prévue pour installer Silverpeas sur JBoss 5, je vais partir de mon installation sur JBoss 4, je vais récupérer les éléments (datasource, JMS, ear) et les modifier pour les adapter à JBoss 5.
-
Script de création de machine virutelle VirtualBox
J’utilise régulièrement des machines virtuelles pour évaluer des produits ou pour élaborer des procédures d’installation. Ce procédé a plein d’avantages, comme pouvoir transférer le résultat sur d’autres machines, repartir facilement d’un environnement vierge ou ne pas polluer mon environnement de travail.
J’utilise un nombre restreint de configurations types. Par exemple, pour toutes les installations de type serveur (JBoss, Glassfish, Hudson CI,…), j’ai configuré une Debian avec Java, MySQL et quelques autres logiciels. Chaque fois que j’en ai besoin, je fais une copie de l’environnement étalon et je travaille sur cette copie.
Le principal défaut de cette procédure est que la duplication de disque virtuel est facile à réaliser, mais pas la duplication de la configuration. J’ai donc décidé de faire un script shell pour automatiser la création de nouvelles machines virtuelles à partir du disque étalon.
-
Installation de Silverpeas
Pour aujourd’hui, je me lance dans une installation de Silverpeas v5, la première version libre. Je pars sur une installation standard, c’est à dire avec JBoss 4.0, le serveur d’application préconisé. Celui-ci est un peu vieillot, mais si ça fonctionne, ce sera un bon début. J’essaierai plus tard sur un JBoss plus récent et/ou un Jonas.
J’ai déroulé la procédure d’installation du début à la fin, sur une machine virtuelle vierge, sous Linux. J’ai utilisé une version de Silverpeas qui n’est pas finalisée, ce qui peut se ressentir à certaines étapes.
-
Persistance dans Google App Engine : JDO, JPA ou ... ?
Le moteur de persistance de Google App Engine va m’obliger à sortir des sentiers battus. En effet, comme beaucoup de jeunes développeur de ma génération, j’ai toujours stocké mes données dans des bases relationnelles. Or Google nous fournit un stockage de nature NoSQL appelé BigTable. Cette technique est propriétaire et a été développée par Google pour le moteur de recherche et Google Earth. Au sein du projet Apache Hadoop!, une équipe a repris les spécifications publiées par Google pour créer un moteur similaire appelé Hbase!. Par conséquent, dans mon projet, il n’y aura pas de SQL, pas de JDBC, pas de Foreign Key,…
Google nous fournit une API de bas niveau pour accéder à ce stockage, et, pour nous simplifier la tâche, il nous propose aussi les APIs classiques JDO et JPA. Naturellement, je serais tenté d’utiliser JPA car je l’utilise régulièrement pour des projets en architecture plus traditionnelle. Il semble par contre que JDO est mieux supporté. Il apparait clairement que le choix n’est pas évident.
Alexis Hassler
J'ai créé la société Sewatech en 2005, pour y exercer mon métier de développeur full stack, à dominante back end.
Vous pouvez me contacter si vous cherchez un développeur indépendant expérimenté (plus de 25 ans d'expérience) pour intégrer votre équipe de projet. Je peux aussi intervenir pour un audit ou une mission de conseil.
Enfin, je donne des formations sur Spring, Vert.x, WildFly,... en intra sur site ou à distance.
