Comment obtenir une véritable modularité d'application en utilisant Akka dans les bundles OSGi?

Question

Lorsque vous utilisez des acteurs Akka, chaque acteur créé est enregistré dans un ActorRegistry. L'ActorRegistry est un singleton, et permet de rechercher et de gérer facilement (démarrer, arrêter, ...) tous les acteurs. Cependant, dans un environnement OSGi, un certain nombre de groupes d'applications peuvent être installés chacun en utilisant des acteurs Akka en interne (et Akka est installé en tant que groupe lui-même). Certains des acteurs d'un ensemble d'applications doivent être disponibles pour d'autres ensembles et, en tant que tels, agir en tant que services exportés. D'autres sont strictement internes au bundle. L'ActorRegistry contient cependant tous les acteurs de tous les bundles (puisque c'est un singleton), donc les deux exportés ainsi que les internes. Cela signifie que même les acteurs utilisés en interne dans un bundle sont disponibles pour tout autre bundle.

Mais j'aimerais avoir plus de contrôle sur les acteurs qui sont disponibles en dehors d'un bundle. Idéalement, chaque bundle aurait son propre ActorRegistry, et déciderait lequel de ses acteurs serait publié en tant que service OSGi.

Alors, quelle serait la meilleure façon d'utiliser Akka pour une application modulaire dans un environnement OSGi, pour obtenir une véritable modularité?

(arrière-plan à ce sujet sur http://blog.xume.com/2011/02/actorregistry-scope-using-akka-in-osgi.html

Answer 1

D'après ce que je me souviens, ActorRegistry était un singleton dans une version antérieure de Akka, et, de ce que je peux voir dans le code maintenant, it no longer is. Maintenant ActorRegistry est une classe finale , avec une instance créée pour objet compagnon Acteur:

object Actor extends Logging { 
    ... 
    val registry = new ActorRegistry 
    ... 
} 

class LocalActorRef { 
    ... 
    def initializeActorInstance = { 
    ... 
    Actor.registry.register(this) 
    ... 
    } 
    ... 
    def stop = { 
    ... 
    Actor.remote.unregister(this) 
    ... 
    } 
    ... 
} 

Ainsi, vous pouvez évidemment créer plusieurs instances du registre

Deuxièmement, comme vous le savez, les acteurs re. gister/désenregistrer eux-mêmes dans ActorRegistry à start/stop méthodes, donc, dans votre cas, je finirais avec subclassing/mélange Actor/LocalActorRef (surcharge start/stop responsable de l'enregistrement, et en ajoutant ici la fonctionnalité que vous cherchez) et/ou en ajoutant le vôtre ActorRegistry.