|
Publicité ' | |||||||||||||||||||||||
|
|
#1 | ||
|
Expert Confirmé Sénior
![]() ![]() Urbaniste Inscription : juillet 2004 Messages : 2 120 ![]() |
Bonjour à tous.
Je travaille à ce jour sur la mise en place d'une plateforme OSGI-Camel. J'ai déjà évalué plusieurs produits comme servicemix, fuseEsb, etc. Dans la doc de Camel, lorsqu’il s'agit d'OSGI on est renvoyé vers servicemix. J'utilise fuse, et aucun problème à signaler. Devant déployer un grand nombre de composants Camel ayant beaucoup de choses en commun j'ai un ensemble de bundles que je partage entre tous ces composants. Du coup en terme de déploiement de la plateforme j'évalue la possibilité de faire ma propre distribution contenant tous ces éléments. Je suis parti de fuse. Mais ne voulant pas écarter d'autres approches trop vite, j'ai aussi fait un projet à partir de servicemix, et un autre à partir du code source de servicemix. Rapidement, je me suis aperçu que ces projets embarquaient beaucoup d'éléments dont je n'ai pas besoin. Étant dans l'optique de faire une distribution personnalisée, je donc repris tout ça à partir de zéro. Au lieu de partir d'une distribution servicemix, fuse ou autre, je ne suis parti de rien. J'ai construit un assemblage de Karaf personnalisé qui pour le moment embarque Karaf, les outils d'admin, jaas, orb, camel-blueprint, et activemq. Pour le moment ça marche plutôt bien. Par rapport à servicemix, je n'ai pas des choses que je n'utilise pas du tout comme nmr, jbi, ... Bref je m’oriente vers une plateforme ultra light (en rapport à servicemix-minimal). Parmi vous, y en a-t-il certains qui ont essayé de faire une "karaf custom distribution" ? Personellement je suis partit de la doc de Karaf qui est pleinne d'erreurs sur ce point. Dans le pon la doc définie une propriété Code xml :
<karaf.version>2.2.2</karaf.version> les chemins son donné en absolut Code shell :
/x1/asf/kar227/manual/src/main/filtered-resources Code xml :
<descriptor>mvn:org.apache.karaf/apache-karaf/2.2.7/xml/features</descriptor> Code xml :
Il y a ce genre de petites erreurs dans tout l'exemple de la doc. Après pas mal de recherches, je me suis écarté de la doc sur la partie org.apache.karaf.features.cfg. J'ai comme dit dans la doc défini mon propre fichier feature et c'est le seul que j'ai référencé dans org.apache.karaf.features.cfg. À lui d'inclure tout ce que doit embarquer la plateforme. C’est beaucoup plus simple. Enfin pour la partie assembly j'ai quelque peut dû modifier l'exemple pour qu'il fonctionne. Par exemple ajouter un « exclude » pour gérer le pb des fichiers *.formatted qui se retrouve dans la distribution. Je pense donc que je vais finir par avoir un projet Karaf custom distribution ne contenant que le minimum pour déployer des routes Camel. Dans lequel je référencerait les features de mon projets principal. Je ne sais pas si c'est la distribution que nous retiendrons au final. Mais je pense que cette expérience est (pour moi) riche s'enseignements. Je pense donc revenir ici vous faire part de celle-ci. A+JYT |
||
|
|
00
|
|
|
#2 | ||||
|
Expert Confirmé Sénior
![]() ![]() Urbaniste Inscription : juillet 2004 Messages : 2 120 ![]() |
Bonjour.
Comme promis, je reviens vous donner les résultats de cette petite expérience. Je vous plante le décor : j'ai un projet «Hermes» dans lequel de nombreuses Routes Camel doivent être déployées. La solution retenue est de déployer des bundles osgi dans un ou des conteneurs karaf. Pour que cela fonctionne il nous faut karaf et quelques éléments supplémentaires. Les bundles camel pour tourner sous osgi ont leurs propres exigences. La documentation de Camel pour les déploiements osgi propose de s'en remettre à ServiceMix. J’ai utilisé cette solution pendant toute la première phase du projet. Au pire ServiceMix peut nous servir de plateforme. Mais serviceMix est un ESB et pour simplement déployer des routes camel c'est peut-être beaucoup de composants dans la plateforme pour rien. J'ai donc cherché à faire une plateforme perso. La principale difficulté que j'ai rencontrée est le choix des versions. En effet quelques éléments de camel ne fonctionnaient pas dans les versions choisies. Alors que ce sont celles qui se trouve dans servicemix/fuseesb. En fait tant servicemix, que fuse, ont patché quelques composants de camel pour éviter de passer à la version supérieure ce qui implique pour eux des évolutions dans leurs propres codes. je suis donc parti sur les versions suivantes : Code xml :
1) étape créer un projet d'assemblage de karaf. la doc http://karaf.apache.org/manual/2.2.7...tribution.html est bien utile même si l'exemple proposé est plein d'erreurs. j'ai décidé de placer les "features" à embarquer dans la distribution dans le fichier features.xml. la doc propose d'en déclarer une partie dans le pom. les mettres dans features permet de construire une plateforme minimale (sans aucun ajout autre que karaf) est d'ajouter par la suite les élements nécéssaires sans avoir à retoucher son pom. créer le fichier pom.xml Code xml :
A+JYT |
||||
|
|
00
|
|
|
#3 | ||||||
|
Expert Confirmé Sénior
![]() ![]() Urbaniste Inscription : juillet 2004 Messages : 2 120 ![]() |
La définition de la plateforme. créer les dossiers comme spécifié dans la doc karaf.
2) créer le fichier src/main/filtered-resources/features.xml il va contenir une référence à tous les fichiers features dont nous avons besoin et définir une feature propre au projet. elle ne contient rien mais est là pour vous permettre de définir des bundle à déployer au démarage de la plateforme. toutes les features définies dans ce fichier apparaitront avec la commande features:list Code xml :
Attention la doc indique dans le pom Code xml :
<descriptor>mvn:org.apache.karaf/apache-karaf/2.2.7/xml/features</descriptor> Code xml :
Code properties :
la doc de karaf indique ensuite de placer un dossier etc avec tous les fichiers conf dans src/main/distribution. le problème avec cette façon de faire et que les fichier seront copier sans aucune vérification. J'ai donc placé tous les fichiers indiqués dans src/main/filtered-resources/etc ainsi il passe par les filtres de l'assemblage et on peut agir sur des variables de substitusion. Copier simplement les contenus des fichiers. il suffit juste de remplacer "my-costom" ou "my-customer" par le nom de votre distribution (pour moi "hermes") on a :
si vous avez installé une distribution karaf vous constaterez qu'il y en a d'autres. si par défaut un de ces autres fichiers doit être modifié pourque votre distribution fonctionne. faites en une copie dans ce dossier et modifiez le. A+JYT |
||||||
|
|
00
|
|
|
#4 | ||||
|
Expert Confirmé Sénior
![]() ![]() Urbaniste Inscription : juillet 2004 Messages : 2 120 ![]() |
les fichier d'assemblage.
la doc karaf indique de créer le fichier : src/main/descriptors/bin.xml en lieu et place pour pouvoir faire une distribution pour windows et une pour unix j'ai créé deux fichiers : src/main/descriptors/unix-bin.xml et src/main/descriptors/windows-bin.xml l'exemple de la doc est peu ou prou correct utiliser les propriété du projet en lieu et place des numéro de verions Attention au premier fileset il corresponds au fichiers que vous avez placé dans etc. si vous excluez un fichier que vous n'avez pas mis dans le dossier il sera manqant et karaf ne fonctionnera pas. si au contraire vous oubliez d'exclure un fichier que vous avez placé dans etc. l'assemblage placera votre fichier et celui de karaf dans le zip ou le tar.gz du coup impossible de savoir celui-qui sera déployé. dernier point sur l'assemblage le jar Branding si vous n'en avez pas il faut retirer le fileset correspondant dans le fichier d'assemblage. unix-bin.xml Code xml :
Code xml :
vous remmarquerez que contrairement à la doc je n'ai pas inclus les fichiers bin/karaf et bin/karaf.bat vu que l'assemblage produit une commande bin/hermes et bin/hermes.bat je n'en vois pas l'utilité. A+JYT |
||||
|
|
00
|
|
|
#5 | ||||
|
Expert Confirmé Sénior
![]() ![]() Urbaniste Inscription : juillet 2004 Messages : 2 120 ![]() |
Le projet branding qui ne fait que définir un jar contenant un fichier texte dont le contenu est affiché au lancement de karaf.
créer un projet maven simple fichier pom.xml Code xml :
créer le fichier src/main/resources/org/apache/karaf/branding/branding.properties Code :
A+JYT |
||||
|
|
00
|
|
|
#6 | ||||
|
Expert Confirmé Sénior
![]() ![]() Urbaniste Inscription : juillet 2004 Messages : 2 120 ![]() |
j'ai donc une plateforme karaf legère et qui référence les features camel.
par rapport à Servicemix qui démarre avec environ 150 bundles actifs je n'ai que le stric minimum. l'installation de la feature camel dans osgi installe quelques bundles servicemix mais juste le nécéssaire. comme j'ai aussi installé camel-blueprint j'ai au total 65 bundles. Code :
Code :
pour mon projet j'ai ajouté une features pour définir un broker active mq par défaut et quelques bundles à moi. notez que j'ai prévu un fichier hermes.cfg pour placer les propriétés de mes bundles. A+JYT |
||||
|
|
00
|
|
|
#7 |
|
Expert Confirmé Sénior
![]() ![]() Urbaniste Inscription : juillet 2004 Messages : 2 120 ![]() |
Bonjour,
je reviens sur ce post pour plusieurs raisons. la première porte sur les critiques que je formulais à propos de la doc. il y a effectivement des pb sur la doc. Ils sont dûs au fait que la doc est généré par maven et le pprojet qui génère cette doc à un bug. du coup les variables au lieu d'appraitre telles-que dans le document final, sont remplacés par les valeurs courrantes du projet (de doc) par maven. Je vais proposer un correctif pour le v3 de karaf. depuis ma publication il s'est passé beaucoup de choses. la distribution présenté ici à quelque peu évolué pour mes besoins. j'ai ajouté au passage JPA (openjpa) mais aussi hl7api (hl7api.sourceforge.net) le support SAP etc. bref ma plateforme c'est enrichie pour mes besoins propres. au passages j'ai rencontré quelques problèmes. utilisant les features définies par karaf (entreprise) je me suis retrouvé confronté à des pb de conflits entre lib qui exportaient les mêmes packages. entre autre le support des transactions. j'ai donc supprimé l'installations de certaines features (karaf entreprises) pour définir les miennes à la places. au final ma distribution est devenue très liée à mon projet. devant aussi regarder l'avenir de la plateforme j'ai commencé à préparer un changement de version (j'utilise karaf 2.2.2 et camel 2.8.1) et là je dois dire que ma distribution n'est pas très simple à définir. j'envisage donc de revnir à une base plus simple. mon idées est d'agir ainsi: définir une distribution karaf-camel dérivé de karaf totalement indépendante de mon projet le but gérer les versions incrémentales de karaf camel activemq et aries (le coeur de camel sur osgi) definir une distribution hermes dérivé de karaf-camel ajoutant les éléments propres à mon projet. J'espère ainsi pouvoir faire évoluer chaque partie à son rythme. j'ai donc repris mon projet de base que j'ai remanié légèrement. je vous en poste une toute première version (Attention je n'ai pas tout testé) A+JYT |
|
|
00
|
|
|
#8 |
|
Membre Expert
![]() ![]() Inscription : janvier 2004 Messages : 1 241 ![]() |
Bonjour,
J'utilise smx3 / camel depuis quelques années maintenant et je suis en train de migrer vers smx4, je découvre donc le monde magnifique d'OSGi ;o) Sur le principe j'aime bien ta démarche de vouloir un environnement d'exécution minimal, même si je ne suis pas sur de comprendre le but. Ton projet final sera distribué et contiendra ta plateforme SMX4 minimale ? Si oui, ok, ca permet de réduire la taille de la distribution, mais sinon, les composants inutiles ne gênent pas en principe vu qu'ils ne sont pas utilisés, ni démarrés. |
|
|
00
|
|
|
#9 |
|
Expert Confirmé Sénior
![]() ![]() Urbaniste Inscription : juillet 2004 Messages : 2 120 ![]() |
J'ai commencé par évalué pluseurs solutions du marché.
puis je me suis concentré sur le couple karaf camel et pour tester j'ai utilise plusieurs distribution pour m'arrêter sur fuse (smx4) mais je suis dans un contexte où la plateforme sera particulièrement chargée. (plusieurs centaines de bundles à déployer) et surtout en terme d'exploitation vu le nombre d'élément métier à gérer j'ai chercher à décharger un maximum l'exploitant d'élement inutiles. ma première idée à été d'arrêter (ou de supprimer) se dont je n'ai pas besoin. mais rapidement j'ai constaté que le travail était plus complexe que de partir de karaf simple. à ce point j'ai donc installé karaf en version minimale et j'ai ajouté les éléments dont j'avais besoint pour déployer mes bundles. la dificulté principable est de choisir les composants qui fonctionne bien entre eux. restait alors le problème de la distributions dans l'entreprise. si pour chque plateforme à installer il faut intaller karaf de base puis tous les éléments nécéssaire avant de pouvoir déployer un bundle métier ça devient prohibitif. c'est ainsi que j'ai connecé à faire ma propre distribution. le but fournir un package clef en main aux exploitants de l'entreprise. la doc custom distribution de karaf était donc la meilleur approche. mais après un an et plusieurs versions j'ai constaté que faire évoluer la distribution n'est pas toujours simple. J'ai des évolution de mes composant qui servent de base à ma solution métier et j'ai des évolutions qui concerne les besoins des éléments entourant karaf et camel. d'où l'idée de séparer les deux. construire une distribution karaf camel (et les composants de base JTA par exemple) et une autre qui s'appui sur la première et ajout les éléments pour ma solution. ainsi je peux dans le premier maitriser et tester indémendement de mon projet global la distribution karaf camel. fondementalement elle n'est donc pas propre à mon usage mais est faite pour déployer des routes camel sur karaf. aujoud'hui pour avoir déployer un première route à partir de rien il suffit de faire unzip du package nommer l'instance karaf la démarrer et faire un features install de la route. je pense que l'usage est sufisement large pour le partager. lorsque le tout sera assez mur et qu'il interesse d'autre personne je pense que le donner à la communauté ne sera pas un problème. en attendant je partage mon expérience et mon code. A+JYT |
|
|
00
|
Copyright © 2000-2013 - www.developpez.com