Espace de fouille

La zone de fouille technologique java-jEE, M2M, noSQL…

Affichage des articles publiés par Frédéric Bouquet

Il est possible de gérer, à partir d’un XWiki existant, une ferme de Wiki assez facilement.

Pour ce faire, il est nécessaire de donner l’utilisateur base de données qui héberge XWiki les droits de création, modification et suppréssion de nouvelles bases de données. Une fois ce pré-requis rempli, il suffit d’installer l’extension « Wiki Manager Application » à partir de l’interface d’administration XWiki.

Tout se passe ensuite dans l’espace WikiManager qui propose une interface d’administration pour la gestion de l’ensemble des sous-wiki.

Chaque sous-wiki ainsi créé est accessible via un alias qui correspond au VHost qui doit pointer vers le XWiki parent.

Notons que cette fonctionnalité arrive par défaut avec le package « XWiki Enterprise Manager » disponible à partir du site de téléchargement de XWiki.

Vue d’ensemble

XWiki est un wiki, et un peu plus… Pour faire court, au dela de la l’édition communautaire des pages à la façon de tous les Wikis, XWiki offre aussi la possibilité d’exécuter de décrire et d’éxécuter des actions au sein de ces pages, ce qui rend à l’aide d’une API étendue, les possibilités d’extension de l’outil illimitées. On peut ainsi trouver dans la communauté des extensions qui ajoutent à la plateforme de base une interface de blogging, un forum ou encore des notifications sur IRC de toutes les modifications de pages.

Cet article présente un guilde d’installation et quelques pistes pour industrialiser la procédure.

Pour cette installation, nous partons du principe que les éléments suivants sont disponibles :

  • apache tomcat 7 installé dans le répertoire CATALINA_HOME (/usr/share/tomcat7/ sous archlinux) [1]
  • mysql 5.5 avec une base de données xwiki
  • le war de xwiki-entreprise [2]

La procédure

La première chose à mettre en place, c’est une nouvelle instance de tomcat. Pour cela, il convient de créer un nouveau répertoire CATALINA_BASE. Disons : /srv/xwiki
Dans ce répertoire, l’instance du tomcat a besoin des répertoires suivants :

  • conf : qui contiendra l’ensemble des fichiers de configuration de notre instance
  • lib : qui contiendra les librairies nécessaires à notre installation de xwiki (cf. plus loin)
  • logs : qui hébergera les différents journaux
  • temp : pour les fichiers temporaires
  • webapps : pour la webapp xwiki
  • work : espace de travail de tomcat

L’étape suivante consiste à installer les fichiers de configuration de tomcat. Pour cela, il convient simplement de copier les fichiers CATALINA_HOME/conf/server.xml et CATALINA_HOME/conf/web.xml dans CATALINA_BASE/conf. Eventuellement, éditer CATALINA_HOME/conf/server.xml pour changer les ports de tomcat si d’autres instances tournent sur la même ip.

Créons aussi un script de démarrage du tomcat :

#!/bin/sh
JAVA_OPTS="-Xmx800m -Xms800m"
CATALINA_HOME=/usr/share/tomcat7
CATALINA_BASE=/srv/xwiki
export JAVA_HOME JAVA_OPTS CATALINA_HOME CATALINA_BASE
 
$CATALINA_HOME/bin/catalina.sh start

Au tour de xwiki maintenant :

  • extraire le war de xwiki dans le dossier CATALINA_BASE/webapps/ROOT
  • éditer CATALINA_BASE/webapps/ROOT/WEB-INF/hibernate.cfg.xml puis commenter les lignes correspondant à hsql pour décommenter celles correspondantes à mysql tout en les adaptant à l’environnement d’install
  • copier le jar du driver mysql [3] dans CATALINA_BASE/lib

Il ne reste plus qu’à démarrer l’instance tomcat via le script start.sh et suivre les instructions qui s’affichent à l’adresse de notre nouvelle installation de xwiki (http://localhost:8080 pour une installation locale sur le port par défaut).

Enfin, voici quelques idées pour aller plus loin que je détaillerai peut être à l’occasion :

  • Le script start.sh n’est pas très industriel, utiliser un script d’initialisation serait plus intéressant. Regarder ici du côté de systemd
  • Utiliser un datasource défini au niveau du tomcat plutôt qu’une connexion directe à la base de données.
  • Centraliser les fichiers de configuration dans /etc/xwiki par exemple
  • Créer un package natif pour la distribution
  • Mettre en place un proxy http ainsi qu’un vhost afin de simplifier l’accès au wiki

Les références

  1. http://tomcat.apache.org/download-70.cgi
  2. http://enterprise.xwiki.org/xwiki/bin/view/Main/Download
  3. http://dev.mysql.com/downloads/connector/j/
  4. La documentation d’install officielle de XWiki : http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation

Aujourd’hui, j’ai eu la chance de participer au premier jour de Devoxx France qui était principalement dédié à des universités, tools in action et labs.

Il m’a été très difficile de faire un choix parmi l’ensemble des sessions proposées. Finalement, mes choix se sont portés sur « Monitoring Open Source pour Java avec JmxTrans, Graphite et Nagios », le Hackergarten (contribution à des projets open source) et « Good Bad and Ugly Maven – a puzzler session ».

La session sur le monitoring fut enrichissante et m’a rappelé un certain nombre de vieux souvenirs de mes essais à l’administration réseau (notamment les outils Nagios, OpenNMS ou lorsque je me cassais les dents sur des trames SNMP), avec une légère nostalgie pour lorsque je voulais devenir physicien… Sauf que là, c’était du JMX et du Graphite. Pour résumer la session, Henri Gomez et Cyrille Le Clerc nous ont passé en revue les différentes solutions qui existaient en java pour faire du monitoring avec comme seule solution viable JMX (coût dérisoire de l’outillage de l’application, développé par des gens qui savaient ce qu’ils faisaient, …).
Une fois l’application de démo outillée, on nous a montré comment utilisé JmxTrans pour transmettre à Graphite les grandeurs remontées par toutes les couches : de l’OS à l’application, en passant par le serveur d’application ou encore la JVM. Une fois cette extraction faite, nous avons eu une présentation très intéressantes de différentes possibilités de visualisation offertes par Graphite afin d’analyser l’activité technique comme métier d’une application Java et de son environnement. A la sortie, je pense qu’à l’unanimité, nous n’attendons qu’une chose : retrouver nos projets habituels pour mettre ce type de solution en place.

Après un petit coucou à Programmatoo où j’ai pu assister à une situation pour le moins… étrange, où un p’tit bout de chou se faisait poursuivre par un petit robot alligator, j’ai rejoint le hackergarten. Deux projets m’intéressaient : XWiki et CRaSH. Afin de découvrir et contribuer aux deux outils, nous avons décidé d’intégrer le shell CRaSH dans XWiki. J’ai ainsi eu la chance de passer mon après midi à assister Vincent Massol lors de la mise en place de cette intégration, avec l’aide précieuse de Julien Viet. Pour le contexte, j’aime présenter XWiki comme un framework de développement caché derrière un Wiki aux fonctionnalités avancées. CRaSH quant à lui est un shell qui peut se plugger à une JVM/application java. Par le biais de commandes développées en Groovy, CRaSH permet d’outiller l’application à laquelle il est attaché pour des besoins d’administration le plus souvent (monitoring des threads, connexions JDBC, accès aux métriques JMX, …). Ici, l’idée était d’ouvrir un accès ssh à une installation XWiki pour permettre l’ajout de commandes CRaSH via les pages XWiki. Joli projet qui s’est avéré être passionnant.

La journée s’est terminée sur une reconstitution du jeu « qui veut gagner des millions » où Nicolas de Loof dans le rôle de l’animateur interrogeait Arnaud Héritier sur quelques étrangetés Maven (Comment ça les devs de surefire aiment jouer au yoyo avec le comportement de certaines fonctionnalités ?). Je pense que vous connaissez tous le style de Nicolas, donc je vous invite très fortement à découvrir cette session pour le moins… originale, lors de sa diffusion sur Parleys.

En bref, tout ceci annonce une suite demain qui promet d’être des plus enrichissantes…

Il n’est pas rare d’avoir dans son entreprise plusieurs dépôts maven, un utilisé pour les SNAPSHOT, l’autre pour les releases. Si vous utilisez le maven-release-plugin, vous avez peut être été confronté au fait que la variable altDeploymentRepository était ignorée.

Pour corriger le problème, rien de plus simple, il suffit d’invoquer maven avec :

 mvn release:perform -Darguments=-DaltDeploymentRepository=http://...

En espérant que cette petite astuce fera gagner à d’autres le temps que j’ai pu perdre de mon côté :)

J’ai eu dernièrement à travailler sur un projet dont la compilation m’affichait sans arrêt le warning suivant :

WARNING
 WARNING Some problems were encountered while building the effective model for MON_PROJET
 WARNING 'dependencies.dependency.systemPath' for LA_DEPENDANCE should not point at files within the project directory, LE_CHEMIN will be unresolvable by dependent projects @ line xx, column yy
 WARNING
 WARNING It is highly recommended to fix these problems because they threaten the stability of your build.
 WARNING
 WARNING For this reason, future Maven versions might no longer support building such malformed projects.
 WARNING

La raison est que ce jar était attaché au projet en utilisant le scope system et était référencé par la balise systemPath, ce qui est une mauvaise pratique.

Une solution que je trouve élégante pour résoudre ce type de problèmes est d’utiliser maven pour créer un dépôt local au build et y faire référence comme une dépendance de mon projet.

Ainsi, j’installe d’abord le jar en question avec la commande suivante :

mvn org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
    -Dfile=LE_JAR
    -DgroupId=LE_GROUPE
    -DartifactId=L_ARTEFACT
    -Dversion=VERSION
    -Dpackaging=jar
    -DlocalRepositoryPath=LE_DEPOT
    -DcreateChecksum=true

La création du checksum est importante sinon Maven râle que la dépendance n’est pas signé.

Une fois cette étape terminée, il faut rajouter la dépendance et ce nouveau dépôt au projet.

Déclaration de la dépendance :

<dependencies>
  <dependency>
    <groupId>LE_GROUPE</groupId>
    <artifactId>L_ARTEFACT</artifactId>
    <version>VERSION</version>
  </dependency>
</dependencies>

Déclaration du dépôt :

<repositories>
  <repository>
    <id>Depot local</id>
    <url>file://LE_DEPOT</url>
  </repository>
</repositories>

Comme nous l’avons découvert dans le précédent article, Apache Ofbiz est un framework qui permet de construire des applications métier. Dans cet article, nous allons explorer plus en profondeur les différentes briques d’une telle application, et plus en particulier, l’emplacement des différents fichiers afin de mieux nous y retrouver dans les explorations à venir.

Basiquement, OFBiz se base sur une architecture 3 tiers : une interface utilisateur, une logique de pilotage et un modèle de données.

La commande ant create-component permet de créer l’ossature d’un nouveau projet. Ce projet sera automatiquement placé dans le dossier hot-deploy et déployé lors du redémarrage de apache Ofbiz.
La commande nous demande plusieurs informations :

  • Le nom du composant : il s’agit ici du nom du projet global
  • Le nom de la ressource : le nom de l’objet métier manipulé. Ce nom servira de base aux noms d’un certain nombre de fichiers.
  • Le nom de la webapp : le nom de l’application web
  • Les permissions de base : un utilisateur doit disposer de cette permission pour pouvoir utiliser l’application

Une fois la commande terminée, nous retrouvons nos différents tiers ainsi :

  • A la base, le modèle de données est défini via des entités dans le fichier entitydef/entitymodel.xml.
  • Au dessus du modèle de données, les services sont responsables de définir la logique métier. Ils sont définis dans servicedef/services.xml. Leurs implémentations seront créées dans le dossier script.
  • Enfin, l’interface utilisateur se définie dans le dossier widget. xxxScreens.xml permettent de définir les différents écrans, leurs composants et les actions associées.Pour permettre l’accès à ces écrans, il va falloir définir une corrélation entre une requête et l’écran correspondant. Cela se définit dans le fichier webapp//WEB-INF/controller.xml

L’ensemble de ces configuration se fait en XML. Maintenant ces quelques bases physiques posées, nous verrons plus tard comment s’effectue la mise en place de la logique d’un projet Ofbiz.

Après l’installation de découverte d’apache ofbiz [1], j’en viens à me demander ce qu’est cet outil et qu’est-ce qu’il peut m’apporter ?
En effet, après le démarrage de l’appli, je me suis retrouvé avec un store et un manager, sans vraiment savoir où aller, ni quoi faire.
Dans cet article, je vais donc tenter de débroussailler un peu la chose et poser les briques qui nous serviront plus tard à aller plus en profondeur…

Lors de mon précédent article, nous nous étions retrouvés avec un exemple de site de e-commerce et une plateforme d’administration associée. Il s’agit de deux applications qui viennent avec le bundle en guise d’exemple. Beaucoup d’autres applications d’exemples arrivent avec ce bundle, de la gestion de projet à la gestion de la comptabilité en passant par les ressources humaines ou le moteur de workflow.

En se rendant à la page http://localhost:8080/ofbiz/, on retrouve la page de présentation de la suite Ofbiz avec en particulier une liste d’application et de sociétés qui utilisent la plateforme. Je suis d’ailleurs particulièrement étonné lorsque je découvre que Jira, le célèbre bugtracker en fait partie.

De ces quelques observations, je pense que l’on peut en conclure qu’ofbiz est avant tout une plateforme de développement d’applications métier. Au dela de ce socle technique, la solution arrive avec un ensemble d’applications pré-conçues pour adresser tous les métiers de l’entreprise. N’étant pas un expert métier de l’une de ces applications livrées, mis à part sur des questions d’ergonomie et d’utilisabilité, je ne pense pas passer trop de temps dans l’immédiat à explorer ce qui est livré. Par contre, toute la partie framework et programmation pourra être intéressante. Un exemple d’appli « from scratch » pourra être intéressant.

Au niveau des fonctionnalités technique, je pense que l’on peut mettre en avant les points suivants qui feront l’objet de ma fouille future de l’outil :

  • chaque application est cloisonnée
  • plusieurs applications peuvent partager un ensemble de données (cas de l’interface d’admin et du store)

Liens :

  1. http://www.espacedefouille.org/premiers-pas-avec-apache-ofbiz-le-progiciel-made-in-apache

Aujourd’hui, j’ai décidé de tenter d’entrer dans le progiciel apache Ofbiz qui regroupe un certain nombre de fonctionnalités, parmi lesquelles : ERP, CRM, SCM, resource planning, gestion de projet, …
En gros, une jolie usine à Gaz mais dont quelques retours que j’ai pu glaner sur le net semblent prometteurs.
Cet article fait état de mes premiers tests.

La première étape a donc été le parcours du site web (http://ofbiz.apache.org/). La page de garde est plutôt jolie et nous fait un certain nombre de promesses sur une large gamme de fonctionnalités. Difficile de résister.
En fouillant plus en détails, il semble que les docs soient très rares et à première vue, je me suis demandé si le projet était encore en vie. Donc direction les ML et là, plus de 250 messages depuis le début du moins et côté bug tracker, un bon nombre d’issues ouvertes ou en cours de résolution ces dernières semaines. En bref : il y a une vie autour du projet malgré le peu de documentations. Donc soit le projet est d’une simplicité enfantine, soit il va falloir remédier à ce manque. Premier point de contribution possible.

Donc allons y, téléchargeons la solution à partir de la page principale. On récupère un zip. Désarchivons…
La doc présente ici propose de lancer ant run-install run.
Après quelques minutes de compilation et d’initialisation, nous avons un système prêt à l’emploi. Allons maintenant à l’adresse http://localhost:8080/catalog. Les crédits pour s’authentifier sont admin:ofbiz.
Nous avons accès à la plateforme d’administration du site de e-commerce, accessible à http://127.0.0.1:8080/ecommerce/control/main.

A première vue, le style ne fait pas très professionnel et je constate un certain nombre de soucis de traduction sur la version Française. Autres points de contribution dont le coût d’entrée est assez faible.
Il est aussi à mon avis dommage que le bundle que l’on télécharge depuis le site ne soit pas directement exécutable. A voir s’il est possible de générer l’application pour qu’elle soit directement téléchargeable et exécutable.

Pour l’instant, nous n’avons vu que la partie e-commerce. Je pense qu’il serait utile d’explorer les autres composants avant d’aller plus en avant dans l’utilisation voir les contributions possibles.

Voici une citation de Benjamin Chaminade que j’ai trouvée intéressante et Ô combien vraie sur le métier de consultant. J’ai donc tenu à vous la faire partager.

 

Il est temps de quitter le métier de consultant quand :

- tu parles de et à ton ordinateur en utilisant le pronom « elle » ;
- les salariés de ton client viennent te voir pour te demander comment fonctionne leur photocopieuse et où sont les meilleurs restaurants aux alentours ;
- tu peux prendre un rendez-vous par téléphone, noter les coordonnées, lire tes mails et te gratter le nez en même temps mais que tu es incapable de savoir ce que tu fais le lendemain sans lire ton agenda ;
- tu regardes les pommes qui poussent dans ton jardin en les appelant délivrables ;
- tu commences à envisager une carrière dans l’armée pour avoir un vrai équilibre vie privée / vie professionnelle ;
- tu es surpris en rentrant chez toi de ne pas avoir besoin d’une carte magnétique pour ouvrir ta porte et de ne pas trouver de questionnaire de satisfaction sur ton lit ;
- tu apprécies les week-ends parce que tu peux travailler à la maison ;
- tu as vu plus de films en avion qu’au cinéma ;
- ton CV ressemble à un générique de fin ;
- tu utilises des mots comme granularité ou paradigme ;
- tu es convié à un rendez-vous à 9 heures et que tu demandes : « matin ou après-midi ? »
- tu vas travailler là où les gens vont habituellement en vacances ;
- tu vas en vacances là où les autres vont d’habitude travailler. La Défense, c’est tellement plus calme au mois d’août !
- tu utilises Excel pour organiser tes vacances ;
- tu ne sais pas quoi répondre lorsque l’on te demande ce que tu fais dans la vie ;
- tu donnes des questionnaires d’évaluation à tes amis après les avoir invité à dîner ;
- tu connais les villes par le code de leur aéroport et les numéros de tous les départements français ;
- Tu te réveilles le matin sans te souvenir dans quelle ville tu es ;
- Tu estimes que tu n’as jamais eu de problèmes dans ta vie, juste des opportunités et des sources d’amélioration ;

Embarquer l’environnement d’exécution d’une application au sein de l’environnement de développement est une pratique courante et pratique. Il en est de même lorsque l’on développe une application cliente pour Bonita Open Solution. Cet article propose ainsi une procédure qui permet d’embarquer le bundle BOS tomcat 5.6.1 pour développer une application web cliente du moteur à partir d’intellij IDEA 11 (version Ultimate) [1].

  • La première étape consiste à télécharger et extraire le bundle tomcat [2] dans un répertoire de travail.
  • Passons à intellij IDEA. Il suffit de créer un nouveau module java avec le support « application server ». A cet écran, il suffit de créer un nouveau serveur tomcat et de pointer vers l’emplacement du bundle.
  • La dernière étape consiste à rendre la librairie cliente de bonita accessible dans la structure du projet (ctrl+alt+shift+S). Dans les Librairies, ajouter la lib bonita-client.jar que l’on retrouve dans les le répertoire lib/bonita du bundle tomcat. Il est aussi possible de spécifier la javadoc [3]
  • Il ne reste maintenant plus qu’à développer et exécuter notre application. Celle ci interagira automatiquement avec le moteur du bundle.
  1. Site officiel d’Intellij IDEA : http://www.jetbrains.com/idea/
  2. Bundle BOS tomcat : http://www.bonitasoft.com/products/BPM_downloads/all
  3. Java doc : http://www.bonitasoft.org/docs/javadoc/bpm_engine/5.6/