Inclusion de ressources supplémentaires avec les bundles OSGi

Question

Je travaille sur un bundle OSGi qui implémente un service comme wrapper autour d'un exécutable natif. Autrement dit, le service exécute l'exécutable avec ProcessBuilder, lui fournit des données et récupère le résultat. Ma question concerne la meilleure façon d'emballer ce paquet. L'exécutable natif inclut un certain nombre de fichiers de données dépendants qui doivent tous être présents sur le disque pour que l'outil puisse s'exécuter. J'ai trouvé beaucoup de références sur le traitement des DLL natives dans OSGi, mais aucune référence aux fichiers associés à un bundle qui doit être présent sur le disque plutôt que simplement récupérable via le classpath.

Je pensais que je pourrais inclure les fichiers exectuable et dépendants directement dans l'archive du paquet, puis extraire par programme dans un répertoire lorsque l'ensemble est démarré. L'autre option que je peux penser est de mettre l'exécutable quelque part et de définir une propriété système qui pointe vers lui ou quelque chose, mais je veux garder la configuration au minimum.

Une solution qui n'est pas spécifique à une implémentation OSGi particulière serait bien, mais si ce n'est pas le cas, j'utilise Equinox.

Merci!

Answer 1

Votre solution fonctionne, bien sûr. Mais vous devez également veiller à arrêter et à supprimer toute ressource que vous avez extraite et démarrée lors de l'installation. Cela pourrait être particulièrement difficile à suivre si un exécutable créait également des fichiers de travail.

Vous devriez le faire parce que l'un des points forts d'OSGi est la gestion du cycle de vie, qui vous permet également de supprimer des ensembles et des services sans laisser de trace. Pour cela, le framework suit tout ce que fait un bundle. Si vous maintenez une exécution exécutable après avoir supprimé l'ensemble installé et l'avoir démarré, la connexion est perdue et peut continuer à fonctionner jusqu'à ce que l'ordinateur soit redémarré (souvent pas une option pour les systèmes intégrés).

Answer 2

Ces fichiers supplémentaires doivent-ils être inscriptibles par le code natif? Sinon, rien ne vous empêche de placer les fichiers que vous aimez dans un paquet. Le problème habituel que vous avez dans OSGi est de travailler sur le chemin vers le fichier car OSGi ne suppose pas qu'un système de fichiers est disponible (ce n'est pas aussi étrange que cela semble si OSGi a démarré dans les périphériques intégrés).

Comment contrôlez-vous où le code natif recherche les fichiers associés? Avez-vous besoin de lui passer un chemin?

Si vous voulez un répertoire à copier ou à déballer des choses, puis utilisez:

org.eclipse.core.runtime.Platform.getStateLocation() 

Ce qui vous donne le répertoire de travail pour le faisceau.

Si vous voulez trouver le chemin d'un fichier particulier dans votre paquet, vous pouvez faire:

org.eclipse.core.runtime.FileLocator.toFileURL((context.getBundle().getEntry("/etc/readme.txt"))) 

Ce qui, dans ce cas, renvoie une URL de fichier au /etc/readme.txt dans le faisceau en cours.

Les deux parties du code supposent qu'elles se trouvent dans la méthode start() de l'activateur.