Devoxx 2017

Me voila au bout de trois jours de conférences suivies au ( ou à je ne capte plus grand chose à cette heure de la journée ) DEVOXX.


DEVOXX, pour celles et ceux qui ne connaissent pas est LA conférence pour les développeurs.
Initialement tournée autour de JAVA et JAVAEE, elle s’est tournée au fil des années vers les autres technologies qui tournent autour de JAVA ( ANGULAR, BIG DATA,…).

A l’instar des années précédentes, j’ai trouvé les conférences de ( grande) qualité. J’ai appris pas mal de choses et certaines conférences m’ont permis de « mettre l’église au milleu du village » sur pas mal de sujets .

Vous trouverez sur cette page la liste des conférences, hands on et autres ateliers de ce millésime. Personnellement, j’ai assisté à pas mal de conférences sur le bigdata ( hadoop, kafka, spark,…). J’ai également été étonné que ni google, ni oracle étaient présents cette année. Doit-on y voir un signe ?

Les conférences seront diffusées gratuitement sur YOUTUBE.

Sur ce, je m’en vais prendre mon train pour retourner dans ma campagne et récupérer de ces trois jours .

 

Découverte de JHIPSTER

Dans la série, je me réveille après les autres, me voici en train de découvrir JHIPSTER.


Pourquoi me direz-vous. En bien je souhaite réaliser un site avec des fonctionnalités assez courantes (CRUD, recherche, identification via réseaux sociaux,…) sans trop me prendre la tête. Et là, je n’ai pas encore trouvé plus simple :).

J’étais tenté de passer par PlayFramework, mais à première vue, JHIPSTER parait plus simple à mettre en œuvre.

Mais bon qu’est-ce qu’il y a sous le capot ?
Un outil de scaffolding basé sur Yeoman fournissant un front angular (1ou 2) un back basé sur spring boot, une couche de persistance pour une base de données (mongodb, cassandra ou SGBDR) et bien plus encore.

Je ne décrirai pas la procédure d’installation car elle est déjà très bien documentée.

Voici plus précisément les fonctionnalités que je teste :
Coté front

  • AngularJS
  • Bootstrap
  • JWT

Coté Back

  • Spring Boot
  • Identification avec Spring Social / Spring Security
  • Persistence avec MongoDB ( Cassandra n’est pas encore supporté pour l’identification via réseaux sociaux )
  • Utilisation de SWAGGERUI pour documenter les API

J’ai toujours été un peu réticent vis à vis des outils de ce type ( appfuse, jboss forge,..) . Mais, là je suis bluffé. Si on veut faire une application de type CRUD sans se prendre la tête à réinventer la roue pour l’identification, l’ administration des logs, la documentation, etc , JHIPSTER est, à mon avis, l’un des meilleurs choix actuellement.

Cependant, cette intégration à un coût. En effet, l’équipe a fait des choix très structurants. Ce qui est normal pour fournir une solution aussi intégrée. Il faut les accepter si on opte pour ce genre de solution. Par exemple, le monitoring des services springboot est uniquement visible par une console web alors quand dans version standard de ce FRAMEWORK, c’est visible via API REST. C’est certes pas mal quand on est tout seul à gérer l’application, mais dès que l’on veut intégrer la supervision dans une entreprise qui dispose déjà d’outils tels que NAGIOS, cela devient plus problématique.
(Supprimé suite au commentaire de J. DUBOIS)

Pour finir, je dirais que l’une des contraintes à accepter lorsqu’on utilise ce genre de FRAMEWORK est qu’il faut rester dans le cadre préétabli pour qu’il y ait une réelle productivité. Si on veut tordre le modèle on risque de perdre en efficacité et en maintenabilité. A titre personnel pour mon use case, je m’en accommode bien et ça me permet de faire plus de choses en JAVASCRIPT que je n’aurai pu faire avec une application réalisée « from scratch ».

Configurer weblogic pour se connecter à une queue TIBCO EMS

Cet article sera un peu moins rock & roll mais pourra peut-être être utile pour certains.
Je souhaite dans le contexte d’une application JEE hébergée sur weblogic consommer les messages d’une queue JMS hebergée sur TIBCO EMS.

Pre-requis

  • Il faut que la queue présente dans TIBCO EMS soit statique et non dynamique
  • Il faut que la queue EMS ait un nom JMDI
  • Il faut que les droits soient positionnés dans EMS

Dépendances

Il faut installer les JARS suivants dans le répertoire lib du domaine weblogic

  • jms.jar
  • jms-2.0.jar
  • tibcrypt.jar
  • tibemsd_sec.jar
  • tibjms.jar
  • tibjmsadmin.jar
  • tibjmsapps.jar
  • tibjmsufo.jar
  • tibrvjms.jar

Configuration weblogic

Il faut réaliser les actions suivantes :

Créer le module JMS et l’assigner sur le serveur managé

Dans ce module JMS, créer une queue distante et renseigner les informations suivantes :

Maintenant renseigner les informations suivantes :

  • Fabrique de contextes initiale JNDI: com.tibco.tibjms.naming.TibjmsInitialContextFactory
  • URL de connexion JNDI : Elle est au format tibjmsnaming://MONSERVEUR:7222
  • Identification : le mot de passe de l’utilisateur
  • Propriété JNDI : le login de l’utilisateur avec la clé java.naming.security.principal
  • Activer le ciblage par défaut

Ensuite, il faut spécifier la destination en indiquant le nom JNDI local et le nom JNDI spécifié sur EMS.

Enfin, il faut spécifier la fabrique de connexion.

sélectionner l’onglet « Fabrique de connexion » et cliquer sur « Nouveau »

Renseigner les informations suivantes :

  • Nom JNDI local : nom JNDI nécessaire au bean MDB pour envoyer les messages
  • Nom JNDI distant : nom JNDI configuré sur EMS
  • Identifiant / Mot de passe : les mêmes que précédemment

Au final vous devriez avoir ce fichier de configuration généré

<?xml version='1.0' encoding='UTF-8'?>
<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms" 
			  xmlns:sec="http://xmlns.oracle.com/weblogic/security" 
			  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
			  xmlns:wls="http://xmlns.oracle.com/weblogic/security/wls" 
			  xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-jms http://xmlns.oracle.com/weblogic/weblogic-jms/1.1/weblogic-jms.xsd">
  <foreign-server name="ForeignServer-0">
    <default-targeting-enabled>true</default-targeting-enabled>
    <foreign-destination name="ForeignDestination-0">
      <local-jndi-name>jms.Queue</local-jndi-name>
      <remote-jndi-name>queue.sample</remote-jndi-name>
    </foreign-destination>
    <foreign-connection-factory name="ForeignConnectionFactory-0">
      <local-jndi-name>jms.TibcoConnectionFactory</local-jndi-name>
      <remote-jndi-name>QueueConnectionFactory</remote-jndi-name>
      <username>weblogic</username>
      <password-encrypted>{AES}vD1uLZ</password-encrypted>
    </foreign-connection-factory>
    <initial-context-factory>com.tibco.tibjms.naming.TibjmsInitialContextFactory</initial-context-factory>
    <connection-url>tibjmsnaming://MONSERVEUR:7222</connection-url>
    <jndi-properties-credential-encrypted>{AES}/8v3owbSW</jndi-properties-credential-encrypted>
    <jndi-property>
      <key>java.naming.security.principal</key>
      <value>weblogic</value>
    </jndi-property>
  </foreign-server>
</weblogic-jms>
weblogic

Consommation des messages via un EJB MDB

@MessageDriven(mappedName = "jms.Queue", activationConfig = {
        @ActivationConfigProperty(propertyName = "acknowledgeMode",
                propertyValue = "Auto-acknowledge"),
        @ActivationConfigProperty(propertyName = "destinationType",
                propertyValue = "javax.jms.Queue"),
        @ActivationConfigProperty(propertyName = "connectionFactoryJndiName", propertyValue = "jms.TibcoConnectionFactory")
})
public class SampleMDBean implements MessageListener {
    @Override
    @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
    public void onMessage(Message message) {
      //
    }
}
jms

Devoxx 2016

Ben voila, j’écris ce billet entre deux confs lors de l’édition 2016 du devoxx.index
QUOI, vous ne connaissez pas devoxx ? c’est à mon avis LA conférence française du développement JAVA, SCALA,BIG DATA.

C’est très très technique et c’est tant mieux. Commerciaux et chefs de projets, vous pouvez passer votre chemin 🙂

J’ai pu notamment faire des hands on sur apache kafka, vert.x et sur la création d’architectures.

Petite nouveauté, les conférences seront disponibles sur youtube ( je ne connais pas encore la chaîne ).

Si vous ne connaissez pas, voici quelques conférences de l’année dernière

Créer des batchs avec JAVABATCH – JSR352

Je suis actuellement en train de tester la JSR 352 ( ou JAVA BATCH). Cette API est une des nouveautés de la spécification JAVA EE 7.  Elle permet ( entre autres ) de lancer des BATCHS depuis un serveur JEE.

the-evolution-of-java-ee-7_5252edf90af4c_w1500

 

Mais vous allez me dire : il y a SPRING BATCH ! Oui, JAVA BATCH est une standardisation de JAVA BATCH avec l’ intégration du moteur dans un serveur JEE. D’ailleurs, SPRING BATCH est désormais compatible avec cette API.

Ce dernier offre la possibilité de contrôler l’état des jobs à travers l’outil d’administration du serveur via le JOB REPOSITORY.

jsr352-schematic

Pour ceux qui connaissent SPRING BATCH et le monde chatoyant des ETL, le concept de la JSR 352 sera assez simple à appréhender :

Un batch est spécifié avec un job qui a plusieurs steps qui sont découpés en étapes de lecture, de transformation et de chargement (ETL).

Avantages

Les principaux avantages à faire tourner les batchs dans un contexte JEE ( si si il y en a ) sont les suivants :

  • On peut utiliser l’outillage du serveur pour monitorer les jobs
  • On dispose de toute la stack JEE (CDI, JPA, JTA,JAX-RS,…) pour développer des batchs
  • Un batch peut être déclenché de plusieurs manières (script, service REST,…)
  • Par rapport aux solutions ETL du marché, on peut avoir des tests unitaires, de la qualimétrie de code avec SONARQUBE,…

Inconvénients

C’est une V1. Il y a encore des choses à améliorer ( gestion des properties par ex)

Définition d’un job

Le job se définit par un fichier XML

Les références des différents élements font appel aux références des beans CDI développés. Dans mon exemple, je n’ai pas utilisé de processor car je ne devais pas transformer les données. J’ai cependant eu besoin de séparer les différents traitements en les parallélisant dans des partitions. Pour déterminer les données de chaque partition, j’ai utilisé un mapper.

Le reader

On voir dans l’exemple que l’injection se fait par CDI. Il faut spécifier le scope Dependent pour que les beans soient accessibles dans le contexte BATCH.

La récupération des données se fait via la méthode open(). Logiquement , on doit récupérer toutes les données à ce moment. Ca peut être problématique avec des très grosses volumétries . Dans ce cas on pourra privilégier le lazy loading.

La lecture de chaque item (ex. une ligne ) se fait dans la méthode readItem().  L’une des choses que je trouve un peu dommage dans l’API BATCH est le manque de générique. En effet, ça aurait été un peu plus « sympa » d’avoir une classe AstractItemReader<T> qui paramètre la méthode readItem().

Le writer

De la même manière on spécifie le writer

Sur l’utilisation de la méthode writeItems(), j’ai la même remarque que pour la méthode readItem() . Un peu de générique, ça n’aurait pas été du luxe….

Le mapper

La propriété « PROP » définie dans le fichier XML et utilisée dans le reader est définie pour chaque partition. Les différentes partitions sont stockées dans un partitionPlan.

Démarrage du batch

Le batch peut se démarrer  de la manière suivante

Ce code peut être appelé depuis une servlet, un service REST …..

Monitoring

Pour suivre l’exécution du batch on peut utiliser les outils du serveur d’applications. Sous glassfish on peut utiliser la commande asadmin.

On peut également utiliser les beans JMX pour monitorer les jobs.

Conclusion

La stack JSR 352 est assez simple à utiliser. Elle est certes perfectible ( absence de générique, gestion des propriétés assez compliquée de prime abord) mais fait le boulot.

Par rapport aux autres solutions (spring batch) elle permet la supervision des batchs via les outils du serveur d’application et peut facilement s’intégrer dans une application JAVAEE.

Un client libre pour Google Drive

Grive ne fonctionnant plus sur ma distribution Debian jessie, je me suis mis en tête de développer un client similaire. Vu que j’ai fait LV2 JAVA, je suis en train de réaliser ce client en JAVA. drive_32dp

Mon objectif , assez modeste j’en conviens,  est de réaliser un client en ligne de commande ( oui je sais Python c’est 100 fois mieux pour ça et java ça pue c’est pas beau etc ) qui permette d’être lancé via un script ou par CRON.

Licence

Ce programme est disponible sur GITHUB sous licence GNU GPLv3.

J’ai encore un doute sur l’attribution de la licence car l’ API GOOGLE est soumise à licence APACHE. Je ne sais pas si je peux faire une distinction entre mon code et les librairies que j’utilise ( si vous avez une info à ce sujet, n’hésitez pas 🙂 )

Création d’un exécutable

Je ne publie pas de binaires pour l’instant car l’utilisation gratuite de l’API est limitée . Par contre, j’expliquerai comment le construire.

Composants utilisés

Fonctionnalités couvertes

Pour l’instant, le programme n’est pas utilisable en l’état. Je ne gère que le téléchargement des fichiers récents dans un répertoire. Il me manque la suppression des fichiers en local, dans drive et l’upload des fichiers.

Je dois aussi blinder mon code avec des tests basés sur powermock et mockito.

La suite dans un prochain épisode 🙂

Retour du DEVOXX

J’ai pu assister aux trois journées de l’édition 2015 du DEVOXX.
C’est actuellement LA conférence JAVA ( & consorts ) française.

J’ai pu participer à beaucoup de conférences et hands on.
Voici celles qui m’ont marquées :

Comment rater ses benchmarks

Très bonne conférence sur la méthodologie à appliquer dans la définition et réalisation des tirs de performance

Refactoring fonctionnel

Très bonne conf de Hadi Hariri (Jetbeains) sur l’ amélioration du code avec JAVA8 . Si on opte pour du refactoring fonctionnel, le code est grandement amélioré et plus facile à tester

Fault tolerant microservices on the JVM

Aussi une bonne conférence par une personne de chez datastax sur la conception de micro services.

Questions/Réponses avec Brian Goetz

Pouvoir poser des questions à l’un des architectes du langage JAVA … Priceless 🙂

Encore un grand merci à toute l’équipe organisatrice. C’était du super boulot.

Lire le contenu d’un fichier texte avec le JDK8

Je suis en train de réaliser quelques POCS sur ELASTICSEARCH et j’en profite pour me (re)mettre à niveau sur le JDK8.

Une des grosses nouveautés du JDK7 et qui a été suivie par le JDK8 est la manipulation de fichiers avec L’API java.nio.file Les classes Path et Files pour ne citer qu’elles, simplifient grandement la vie du développeur.

Voici un rapide exemple

Lire le contenu d’un fichier texte et mettre le tout dans une chaîne de caractères

Version JDK6

 

Version JDK7

Version JDK8

Bon vous allez me dire, il était temps, et vous n’avez pas tort. En tout cas, on notera que ça va dans le bon sens, à savoir éviter de se tartiner une dizaine de lignes de code pour réaliser une opération aussi basique

Charger des documents JSON dans ELASTICSEARCH via LOGSTASH

Me voila avec ma stack ELK fraîchement installée. formation-elasticsearch.png

Voici un cas d’utilisation assez simple :Je recherche à insérer au fil de l’eau des documents JSON dans l’index ELASTICSEARCH. Pour ceci on peut le faire de plusieurs manières :

  • Utiliser un ETL (ex. TALEND)
  • Utiliser un programme manipulant l’API ELASTICSEARCH
  • Utiliser LOGSTASH

Cette dernière brique était dans un premier temps dédiée aux LOGS. Dorénavant, elle se rapproche d’un ETL.

Voici le cas (assez simple j’en conviens) que je vais mettre en place

Screen_Shot_10-30-14_at_04.42_PM.PNG

Configuration de LOGSTASH

LOGSTASH s’exécute dans mon cas comme un agent. Il faut créer le fichier de configuration suivant dans le répertoire /etc/logstash/conf.d :

Dans le premier bloc (input) je spécifie que je cherche à traiter les fichiers json qui sont dans mon répertoire et qu’ils sont multilignes.

Ensuite dans le bloc filter , j’applique une transformation pour les mettre en JSON. Enfin dans le dernier bloc ( output) j’affiche dans la sortie standard ( stdout() ) le résultat et je charge dans elasticsearch le document JSON ainsi chargé.

Chargement des données Il faut pour cela redémarrer logstash

Et logiquement, vous devriez voir dans les logs d’ELASTICSEARCH des lignes qui ressemblent à ça

http://127.0.0.1:9200/index/document/_search ///

Visualisation dans KIBANA

Je ne décrirais pas cette partie car je suis encore en cours d’exploration. Voici néanmoins un bon point de départ pour ceux que ça intéresse