quel est l'intérêt de séparer deux exécutions java pour minig : le backend et le frontend, sachant que tomcat au démarrage de l'application peut lancer le backend sans soucis dans sa propre instance java, ça complexifie le déploiement alors qu'il me semble qu'un simple war pourrait faire l'affaire.
L'objectif de cette archi à 2 jvm (plutot 3 sur install "réelle") est de pouvoir distribuer l'application sur plusieurs serveurs du type : un seul frontend avec uniquement l'ui gwt en javascript + les servlets gwt rpc, plusieurs backend MiniG, selectionnés par exemple en fonction du nombre de users connectés.
quel est l'intérêt d'utiliser des morceaux d'eclipse qui utilisent du jni ça limite fortement le "run everywhere", en effet sur mon FreeBSD je me retrouve obligé de recompiler des morceaux d'eclipse pour avoir eclipse_1020.so et eclipse_1115.so afin de tester les snapshots mis à disposition. Est ce que l'avantage des bibliothèques d'eclipse utilisées (celle qui nécessite le jni) est si important au niveau de la facilité de code qu'il est *vraiment* plus inétressant de les utiliser ? je trouve que ça complexifie le packaging (je voudrais faire un ports FreeBSD) et limite la portabilité.
Les derniers builds disponibibles sur le site n'incluent plus les fragments (terminologie eclipse) qui comportent du code natif, car il ne sont pas utilisés sur mes plateformes de test (linux x86 et linux x86_64)
le backend (dont je ne comprends toujours pas pourquoi il ne tourne pas directement dans tomcat :)) utilise un script bash pour démarrer alors qu'un script shell posix ferait largement l'affaire (enfin ça je fournirai un patch dès que j'aurais compris l'intérêt de ne pas mettre le backend dans le tomcat).
C'est du bash plutot que du posix car je n'ai testé qu'avec bash, donc plutot que de mettre "/bin/sh" et que ça plante dès que "/bin/sh" n'est plus bash, je préfère "déclarer" dans mon script que je n'ai testé qu'avec bash.
Pourquoi pas dans le tomcat : l'objectif est de faire tourner le backend sur une machine séparée du frontend, de plus les recommandations officielles sur la plateforme equinox server sont d'utiliser plutot un serveur web "embedded in equinox" que "equinox embedded in server". Le backend n'est pas une "appli web j2ee" mais bien une "equinox server application".
Pourquoi des chemins vers des fichiers de configurations en DUR et très linux-only (/etc/...) pour le packaging FreeBSD moi j'aurai je voudrai les mettre dans /usr/local/etc/minig par exemple (enfin ça doit pas être trop compliqué à mettre en oeuvre.
Oui, toute la conf est dans /etc/minig et c'est en dur. Suis pas très chaud pour avoir une variable de conf "conf_prefix=/usr/local" ou pour les mettre en relatif. Principalement parce que j'aime pas quand j'interviens sur un serveur devoir faire un "locate backend_conf.ini" (et me prendre un locate command not found un coup sur 2) pour savoir ou l'admin a déployé le produit...
J'espère que mon post est compréhensible et que les devs comprennent bien que je ne crache pas du tout sur minig, j'essaye d'être constructif et de comprendre une archi qui de prim'abord me parait étonnante.
Oui l'archi est étonnante, elle permet au webmail de se comporter vraiment comment un client lourd, avec des threads dans le backend qui réalisent toutes les opérations que ferait un client lourd (gestion de cache, refresh auto des folders, indexation full text en tache de fond). Dans l'idéal vous avez 1 tomcat avec le frontend, 1 backend posé "pas loin" du serveur cyrus sur un autre serveur, et 1 serveur d'indexation solr posé sur un troisième serveur pour gérer les index fulls text des boîtes mail.
J'espère avoir répondu a une partie de vos interrogations.
[^] # Re: MiniG quelques interrogation sur l'archi
Posté par Thomas Cataldo (site web personnel) . En réponse à la dépêche Groupware OBM et Webmail MiniG, paquets Debian. Évalué à 2.
quel est l'intérêt de séparer deux exécutions java pour minig : le backend et le frontend, sachant que tomcat au démarrage de l'application peut lancer le backend sans soucis dans sa propre instance java, ça complexifie le déploiement alors qu'il me semble qu'un simple war pourrait faire l'affaire.
L'objectif de cette archi à 2 jvm (plutot 3 sur install "réelle") est de pouvoir distribuer l'application sur plusieurs serveurs du type : un seul frontend avec uniquement l'ui gwt en javascript + les servlets gwt rpc, plusieurs backend MiniG, selectionnés par exemple en fonction du nombre de users connectés.
quel est l'intérêt d'utiliser des morceaux d'eclipse qui utilisent du jni ça limite fortement le "run everywhere", en effet sur mon FreeBSD je me retrouve obligé de recompiler des morceaux d'eclipse pour avoir eclipse_1020.so et eclipse_1115.so afin de tester les snapshots mis à disposition. Est ce que l'avantage des bibliothèques d'eclipse utilisées (celle qui nécessite le jni) est si important au niveau de la facilité de code qu'il est *vraiment* plus inétressant de les utiliser ? je trouve que ça complexifie le packaging (je voudrais faire un ports FreeBSD) et limite la portabilité.
Les derniers builds disponibibles sur le site n'incluent plus les fragments (terminologie eclipse) qui comportent du code natif, car il ne sont pas utilisés sur mes plateformes de test (linux x86 et linux x86_64)
le backend (dont je ne comprends toujours pas pourquoi il ne tourne pas directement dans tomcat :)) utilise un script bash pour démarrer alors qu'un script shell posix ferait largement l'affaire (enfin ça je fournirai un patch dès que j'aurais compris l'intérêt de ne pas mettre le backend dans le tomcat).
C'est du bash plutot que du posix car je n'ai testé qu'avec bash, donc plutot que de mettre "/bin/sh" et que ça plante dès que "/bin/sh" n'est plus bash, je préfère "déclarer" dans mon script que je n'ai testé qu'avec bash.
Pourquoi pas dans le tomcat : l'objectif est de faire tourner le backend sur une machine séparée du frontend, de plus les recommandations officielles sur la plateforme equinox server sont d'utiliser plutot un serveur web "embedded in equinox" que "equinox embedded in server". Le backend n'est pas une "appli web j2ee" mais bien une "equinox server application".
Pourquoi des chemins vers des fichiers de configurations en DUR et très linux-only (/etc/...) pour le packaging FreeBSD moi j'aurai je voudrai les mettre dans /usr/local/etc/minig par exemple (enfin ça doit pas être trop compliqué à mettre en oeuvre.
Oui, toute la conf est dans /etc/minig et c'est en dur. Suis pas très chaud pour avoir une variable de conf "conf_prefix=/usr/local" ou pour les mettre en relatif. Principalement parce que j'aime pas quand j'interviens sur un serveur devoir faire un "locate backend_conf.ini" (et me prendre un locate command not found un coup sur 2) pour savoir ou l'admin a déployé le produit...
J'espère que mon post est compréhensible et que les devs comprennent bien que je ne crache pas du tout sur minig, j'essaye d'être constructif et de comprendre une archi qui de prim'abord me parait étonnante.
Oui l'archi est étonnante, elle permet au webmail de se comporter vraiment comment un client lourd, avec des threads dans le backend qui réalisent toutes les opérations que ferait un client lourd (gestion de cache, refresh auto des folders, indexation full text en tache de fond). Dans l'idéal vous avez 1 tomcat avec le frontend, 1 backend posé "pas loin" du serveur cyrus sur un autre serveur, et 1 serveur d'indexation solr posé sur un troisième serveur pour gérer les index fulls text des boîtes mail.
J'espère avoir répondu a une partie de vos interrogations.