Very informative indeed. But it contains not so many alternative when it comes to my specific issue.
>>>> The bean should not expose the ActorSystem directly to consumers of its service. Instead it is recommended to offer ActorRefs to components within the ActorSystem to clients; these can be the result of looking up actors using “system.actorFor(...)” or preferably asking the target actor’s parent to send back the reference (which ensures that the actor system is ready to receives requests before clients can access it). >>>> This is the closest to what i am talking about specifically here. But things like: 1 - "preferably asking the target actor’s parent to send back the reference" sounds weird. *How do you get the ref of the parent in the first place ?* This boils down to what i was originally asking how to do with dynamic composition. a - The only thing i can think of is to have a specific configuration file (would be great to have a standard), where you could specify those things. E.g. the Actors and their parents, which would ultimately give the path. In other words, we have a declarative dependency injection in config files. Not typeSafe but what else can we do ? b- With that configuration, one can go and ask for the ref of the actors that he needs. c - We could have a central config or multiple config dedicated per actor, which ensure their isolation. d- Beside, to avoid pooling maybe using AKKA Event Bus would be the way to go. Instead of asking the supervisor all the time. One could subscribe to events related to the presence/birth/creation/coming-to-life in the system of some actors of interests. Any shared experience on the matter? or else any comments on my proposal ? Now concerning the part of the blog added above and the suggestion made, it means that the beans containing the actor system, would have access to the configuration file, so it can poll the presence/readiness of some actor such that to return them to the consuming service. A Problem arise which is that in turn, if the service in question needs to be instantiated with the actor ref, then that's not good because we propagate the loss of typesafety in the non actor part of our system that connect to actor. On Monday, October 19, 2015 at 4:27:32 AM UTC-4, √ wrote: > > Let me be clear: We have no beef with enterprise Java :) > > As for Dependency Injection with Akka, this blog post should be > informative: > http://letitcrash.com/post/55958814293/akka-dependency-injection > > On Mon, Oct 19, 2015 at 10:13 AM, Richard Bradley < > [email protected] <javascript:>> wrote: > >> You can use any JVM dependency injection framework you prefer, such as >> Guice. >> >> I think that DI is less fashionable amongst Akka users as it is amongst >> "enterprise Java". I rarely see DI in Akka examples or Akka codebases. >> >> HTH >> >> >> Rich >> >> >> On Friday, October 16, 2015 at 11:05:40 AM UTC+1, Maatary Okouya wrote: >>> >>> I'd like to know if there is some pattern to handle dynamic dependency >>> injection. >>> >>> This concern the situation where we have supervision hierarchy. Let say >>> I have a service Z that depend on a service c which is part of the a -> b >>> -> c hierarchy. >>> >>> Clearly Z does not own C, but would appreciate to use c. >>> >>> It seems to me that Z needs to know that hierarchy in advance. In a >>> sense that would defeat the all purpose of dependency injection. I don't >>> want to couple Z to know that hierarchy. It may change in the future. >>> >>> So I wonder how this kind of things work in general ? >>> >>> I am thinking of using some configuration file, where this kind of >>> information would be set. In other words, the architecture of the system >>> would not be hardwire in the actor, but provided in a configuration, that >>> the actor could use to request the service he needs. >>> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> --- >> You received this message because you are subscribed to the Google Groups >> "Akka User List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Cheers, > √ > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
