En utilisant JavaCompiler dans un OSGi Bundle

Question

Je suis en train de refactorisation une application Java à utiliser OSGi. Une fonctionnalité de l'application est la compilation Java à la volée en utilisant javax.tools.JavaCompiler. Dans l'application d'origine, ce processus fonctionnait en alimentant le compilateur du chemin de classe existant, comme cela. Toutefois, cela ne fonctionnera pas dans un ensemble OSGi car le chemin de classe ne contient plus les chemins nécessaires. Dans la version OSGi refacturée de l'application, le compilateur doit avoir accès aux classes qui se trouvent dans le même paquet que le code ci-dessus, ainsi qu'aux classes des autres bundles. Comment est-ce que je rends le compilateur conscient de ces classes?

J'ai pensé deux solutions possibles:

1. Donnez le compilateur utilisé par l'classloader le paquet contenant le code ci-dessus, car il est au courant de toutes les classes nécessaires. Cependant, cela ne semble pas une solution viable d'après ce que j'ai lu here et here.
2. Générez le chemin de classe en utilisant les emplacements physiques des ensembles installés. J'ai regardé org.osgi.framework.Bundle.getLocation() mais je ne suis pas sûr si ce serait une solution fiable. Les chemins que je récupère (au moins lors du déploiement dans Eclipse) sont relatifs et je ne suis pas sûr qu'ils puissent être utilisés sur toutes les plates-formes et toutes les situations.

Est-ce que l'option deux ci-dessus semblent possibles? Y a-t-il une meilleure solution?

Answer 1

J'ai créé un exemple de travail sur GitHub.

Il n'est pas l'option 1 ou 2, il crée une JavaFileManager coutume qui regarde à travers tous les faisceaux et récupère leurs ressources.

choses à prendre en considération:

• Il utilise l'API du compilateur JSR 199, mais il ne fonctionne que sur le compilateur OpenJDK/Sun, le compilateur Eclipse JDT semble cassé à cet égard.
• Je n'ai testé sur Equinox, je n'utilise un code spécifique de l'équinoxe, il devrait fonctionner sur d'autres mises en œuvre.
• Il n'est pas optimisé, il peut donc être lent et/ou gourmand en mémoire.
• Il enregistre un écouteur de faisceau de sorte qu'il videra son cache de classe quand un paquet qui offre un certain paquet résout ou résout
• Il n'est pas très déterministe pour les paquets fractionnés, je pense.
• Il utilise l'API BundleWiring, qui a été introduit dans OSGi 4.3, donc il ne fonctionnera pas sur les implémentations OSGi âgées de OSGi (Karaf 2.x par exemple)

Je dois mentionner Technology Excruciation, son exemple a aidé moi énormément.