Spring first step

[Rich Dougherty]

Hi guys

FYI I've pushed a small working Spring example to the wip-spring-rich branch. This is just a tiny proof of concept that uses dependency injection to create an ActorSystem and a couple of Actors and ActorRefs. Spring creates and shuts down the ActorSystem. It also creates the Actors in the ActorSystem via a SpringBridge class. The Actors have a dependency-injected parameter.

https://github.com/akka/akka/blob/wip-spring-rich/akka-samples/akka-sample-spring/src/main/resources/spring.xml

https://github.com/akka/akka/blob/wip-spring-rich/akka-samples/akka-sample-spring/src/main/scala/sample/spring/Main.scala

I'm not really sure if this is the right way to go, but I guess it shows that it's possible to get at least something going. If the general approach is right then it would be pretty easy to provide some plumbing to make it a lot easier to use, e.g. Akka-specific annotations or something like that.

Cheers

Rich

[√iktor Ҡlang]

Great stuff Rich!

I think the main use-case is to be able to inject Spring-managed beans into Actor instances and not inject ActorRefs into Spring beans.

Cheers,

√

--
You received this message because you are subscribed to the Google Groups "Akka Developer List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Viktor Klang
Director of Engineering

Typesafe - The software stack for applications that scale
Twitter: @viktorklang

[Roland Kuhn]

Yes, indeed: let’s try to get as far as possible without using system.actorOf, since

– long-term that is supposed to go away (*), and

– if that is the way to create DI actors then that will defeat the whole purpose of the supervision hierarchy.

Creating Actors according to DI templates is not impossible under this constraint, since the Props.creator could ask Spring to create the actual Actor instance, making it easier to inject beans into it.

What does the silent, lurking majority think?

Regards,

Roland

(*) making system.actorOf work has been a huge pain due to its synchronous-yet-asynchronous nature and it makes it way too easy to create degenerate actor systems with only top-level actors, hence we are starting to think about how we could be rid of it; one way would be to require a Props when starting an ActorSystem, which would then be used to create the Guardian actor

Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Empowering professional developers to build amazing apps.
twitter: @rolandkuhn

[Josh Long]

Interesting!

People wont want to inject Actors themselves, just ActorRef clients
which presumably live under the supervisory hierarchy. Typed clients,
too. And they'll definitely want to start things up inside of Spring.
it should also be possible to expose actors from within Spring. I
prototyped support for this sort of thing before, but the support was
two-fold, and simple:

- support @Actor stereotype annotations
- support @ActorRef on fields in Spring using an annotation processor
a la the support for @PersistenceContext
http://www.joshlong.com/jl/blogPost/supporting_your_own_field_or_method_injection_annotation_processors_in_spring.html

I'd be happy to support any development on this from the Spring side.

Thanks,
Josh Long
Spring Developer Advocate
SpringSource, a Division of VMware
http://www.joshlong.com || joshlong.com || http://twitter.com/starbuxman

[Dean Wampler]

I'm a little confused here. Why would you replace a few lines of Scala with a few dozen lines of XML? How is that better?

Dean Wampler, Ph.D.
@deanwampler
http://polyglotprogramming.com

[Roland Kuhn]

Hi Josh,

10 mar 2013 kl. 21:20 skrev Josh Long:

> Interesting!
>
> People wont want to inject Actors themselves, just ActorRef clients
> which presumably live under the supervisory hierarchy.

So you mean to only use system.actorFor, not actorOf? That should be okay, but I’d be interested in knowing why you propose such a complicated thing to replace a simple “context.actorFor(config.getString("my.service.actor-path"))”? Or is it to support injection of ActorRefs into non-Actor beans?

> Typed clients,

What exactly do you mean by this? ActorRef is untyped, and ChannelRef injection would be awkward because the configuration would not be available to the compiler for verification. I guess you want to perform the check at runtime? (i.e. ref.narrow[MyTypes]: ChannelRef[MyTypes])

> too. And they'll definitely want to start things up inside of Spring.
> it should also be possible to expose actors from within Spring. I
> prototyped support for this sort of thing before, but the support was
> two-fold, and simple:
>
> - support @Actor stereotype annotations
> - support @ActorRef on fields in Spring using an annotation processor
> a la the support for @PersistenceContext
> http://www.joshlong.com/jl/blogPost/supporting_your_own_field_or_method_injection_annotation_processors_in_spring.html
>
> I'd be happy to support any development on this from the Spring side.

What kind of development would be needed as far as you can foresee?

Regards,

Roland

[Josh Long]

Everything done in XML could as easily be done using Java config and annotations. In a final integration, there's no need for any of the classes that support the Spring and Akka integration to be visible beyond a simple, enabling annotation (@EnableActors or something like that that would exist in a final solution) on a configuration class which itself needn't be any more complicated than an empty class and an annotation or two. Once such an Akka-Spring integration was installed, then registering and configuring actors would happen as easily as having something declarative in the actor definition itself like an @Actor annotation. In this arrangement you have an extra configuration class than if you didn't involve Spring, but you'd write less per actor, not more. The configuration class otoh gives you Spring. The real benefit of a solution supporting Spring isn't the opportunity to write less total lines of code per actor (though you'd get that too), its to be able to manage the beans and their dependencies using Spring (aop, di, life cycles) and integrate all the mature code and APIs that live in Spring. Thought about another way: it would also be an opportunity to integrate Akka with all of the mature code and APIs that live in Spring :)

I imagine this sort of arrangement for a start:

// spring class

@Configuration 

@EnableAkkaActors 

@ComponentScan("a.aimplepackage.name")

class AkkaConfiguration {} 

package a.aimplepackage.name;

import ...

@Actor

public class SubscriptionActor ... {

  @Inject ABean aBean ;

 ...

}

--
Dean Wampler, Ph.D.
@deanwampler
http://polyglotprogramming.com

--

You received this message because you are subscribed to the Google Groups "Akka Developer List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

[Roland Kuhn]

Hi Josh,

you’re tackling this from the end which I do not (yet) understand: what would that buy me over straight actor code without Spring? I’m not saying that there is no advantage, but it would help spelling out precisely what the benefits are.

Or from a different angle: who is supposed to create that SubscriptionActor and how am I supposed to see in the source how it is going to be configured? If I were just to say “context.actorOf(Props[SubscriptionActor])” that would leave my “aBean” uninitialized, right?

Regards,

Roland

[Rich Dougherty]

Hi Roland

The thing I'm experimenting with now is an 'actor' scope. This would be a Spring scope that is tied to the lifetime of an actor. The scope would be available when constructing a bean, in its preStart and in its postStop. The scope would be ended after postStop, automatically destroying any Spring-configured beans.

Another benefit is that we could let Spring access the actor's context, provided we could guarantee this only happened in construction, preStart, etc. That would allow Spring to be fully involved in creating child Actor/ActorRef pairs.

That seems like it would make it possible for folks to create full actor trees from Spring config (if that's what they wanted to do).

Cheers

Rich

[Roland Kuhn]

Hi Rich,

11 mar 2013 kl. 08:54 skrev Rich Dougherty:

Hi Roland

The thing I'm experimenting with now is an 'actor' scope. This would be a Spring scope that is tied to the lifetime of an actor. The scope would be available when constructing a bean, in its preStart and in its postStop. The scope would be ended after postStop, automatically destroying any Spring-configured beans.

That sounds very useful!

Another benefit is that we could let Spring access the actor's context, provided we could guarantee this only happened in construction, preStart, etc. That would allow Spring to be fully involved in creating child Actor/ActorRef pairs.

That seems like it would make it possible for folks to create full actor trees from Spring config (if that's what they wanted to do).

That is a bit what I’m afraid of: making the structure of the actor hierarchy configurable. The point of the supervision hierarchy is to handle failure in line with the logical structure of the application, and that is something which needs proper design. Therefore I don’t think making it configurable after the fact is a good idea.

We should first focus on viewing an actor system (or actor tree) as something which interacts with a DI container “as a whole”, i.e. the internal structure is fixed. There is enough to be done here: injecting beans into actors and exposing the services of the actor system to other beans. Let us start with that part.

Regards,

Roland

[Rich Dougherty]

On Mon, Mar 11, 2013 at 9:01 PM, Roland Kuhn <goo...@rkuhn.info> wrote:

11 mar 2013 kl. 08:54 skrev Rich Dougherty:

Another benefit is that we could let Spring access the actor's context, provided we could guarantee this only happened in construction, preStart, etc. That would allow Spring to be fully involved in creating child Actor/ActorRef pairs.

That seems like it would make it possible for folks to create full actor trees from Spring config (if that's what they wanted to do).

That is a bit what I’m afraid of: making the structure of the actor hierarchy configurable. The point of the supervision hierarchy is to handle failure in line with the logical structure of the application, and that is something which needs proper design. Therefore I don’t think making it configurable after the fact is a good idea.

I hear what you're saying, but I'm not sure letting Spring create ActorRefs is always bad, and it might significantly decrease the usefulness of the integration if it couldn't do so.

"Configurable", to my mind, would probably mean a pair of configurations: a production configuration (which is carefully designed) and a unit-testing configuration (with mock/probe actors). This is IMO pretty much the same way as we often suggest people accept ActorRefs in Actor constructors so that they can mock the actors when testing. Nothing too fancy, just some annotations/XML vs the code approach we already recommend.

   class MyActor(@ActorRef wellKnownService: ActorRef) { … }

Which isn't to say that I'm super pro-Spring configuration for everything. Probably wiring up an entire actor supervision hierarchy with Spring would be impossible anyway since actor initialisation will often involve asynchronous stuff like message passing. Not everything can be handled with DI at construction. But Spring is possibly good for the simple DI at construction case.

We should first focus on viewing an actor system (or actor tree) as something which interacts with a DI container “as a whole”, i.e. the internal structure is fixed. There is enough to be done here: injecting beans into actors and exposing the services of the actor system to other beans. Let us start with that part.

Injecting beans into actors: yes!

Exposing the services of the actor system to other beans: what did you have in mind here? I think users would probably want to access a few ActorRefs at whatever well-known locations form the actor system's API.

Cheers

Rich

[Rich Dougherty]

Hi Josh

Thanks for the link, that should be really helpful once I get to thinking about annotations. At the moment I'm doing things manually in XML, but I'm sure many users will be keen on things happening with fewer angle brackets!

The offer of help is welcome too. I'm still just exploring, but I'll post my progress here. If/when it gets to that stage, would you be happy to review code?

Cheers

Rich

[Rich Dougherty]

Ha ha good question!

At the moment I'm just exploring Spring and I'm starting off doing things in the simplest (and most verbose) way. Once some common patterns are figured out they can be expressed as Spring annotations, or even custom annotations like Josh suggests.

Even if we don't get to that stage then at least documenting a few Spring/Akka patterns might be helpful for users who are looking for guidance on how to integrate the two.

Cheers

Rich

[Roland Kuhn]

11 mar 2013 kl. 09:55 skrev Rich Dougherty:

On Mon, Mar 11, 2013 at 9:01 PM, Roland Kuhn <goo...@rkuhn.info> wrote:

11 mar 2013 kl. 08:54 skrev Rich Dougherty:

Another benefit is that we could let Spring access the actor's context, provided we could guarantee this only happened in construction, preStart, etc. That would allow Spring to be fully involved in creating child Actor/ActorRef pairs.

That seems like it would make it possible for folks to create full actor trees from Spring config (if that's what they wanted to do).

That is a bit what I’m afraid of: making the structure of the actor hierarchy configurable. The point of the supervision hierarchy is to handle failure in line with the logical structure of the application, and that is something which needs proper design. Therefore I don’t think making it configurable after the fact is a good idea.

I hear what you're saying, but I'm not sure letting Spring create ActorRefs is always bad, and it might significantly decrease the usefulness of the integration if it couldn't do so.

Yes, agreed, but what we are talking here is not a technical issue but a psychological/social one. It is not about “not allowing”, it is about focusing on the right thing first. Allowing people to shoot themselves in the foot has in all previously explored cases led to a lot of feet getting hurt, hence care must be taken.

To illustrate my technical point: an actor which accepts an injected child would only know how to deal with that child’s failures if those failure characteristics were part of the injection contract. Until we can express this notion I would not want to go in that direction, even though—as I said—I agree that it can be very useful.

"Configurable", to my mind, would probably mean a pair of configurations: a production configuration (which is carefully designed) and a unit-testing configuration (with mock/probe actors). This is IMO pretty much the same way as we often suggest people accept ActorRefs in Actor constructors so that they can mock the actors when testing. Nothing too fancy, just some annotations/XML vs the code approach we already recommend.

   class MyActor(@ActorRef wellKnownService: ActorRef) { … }

But this is the benign kind of looking up another actor, right? `actorFor` is fine …

Which isn't to say that I'm super pro-Spring configuration for everything. Probably wiring up an entire actor supervision hierarchy with Spring would be impossible anyway since actor initialisation will often involve asynchronous stuff like message passing. Not everything can be handled with DI at construction. But Spring is possibly good for the simple DI at construction case.

We should first focus on viewing an actor system (or actor tree) as something which interacts with a DI container “as a whole”, i.e. the internal structure is fixed. There is enough to be done here: injecting beans into actors and exposing the services of the actor system to other beans. Let us start with that part.

Injecting beans into actors: yes!

Exposing the services of the actor system to other beans: what did you have in mind here? I think users would probably want to access a few ActorRefs at whatever well-known locations form the actor system's API.

Yes, exactly.

Regards,

Roland

Cheers

Rich

--
You received this message because you are subscribed to the Google Groups "Akka Developer List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Rich Dougherty]

On Mon, Mar 11, 2013 at 10:10 PM, Roland Kuhn <goo...@rkuhn.info> wrote:

To illustrate my technical point: an actor which accepts an injected child would only know how to deal with that child’s failures if those failure characteristics were part of the injection contract. Until we can express this notion I would not want to go in that direction, even though—as I said—I agree that it can be very useful.

If the scope was configured as 'singleton' then the actor would currently be created outside the actor somewhere, probably under "/user".

If it was configured as 'actor' then the actor would be created as a child of the current actor, with whatever supervision implications. It is identical to context.actorOf(Props(SpringHelper.createActor("x"))) in the actor's constructor.

But good points. Probably the singleton-ish path is what we're more interested in, especially so that we can provide these singleton actors to other beans so they can interface with the actor system.

"Configurable", to my mind, would probably mean a pair of configurations: a production configuration (which is carefully designed) and a unit-testing configuration (with mock/probe actors). This is IMO pretty much the same way as we often suggest people accept ActorRefs in Actor constructors so that they can mock the actors when testing. Nothing too fancy, just some annotations/XML vs the code approach we already recommend.

   class MyActor(@ActorRef wellKnownService: ActorRef) { … }

But this is the benign kind of looking up another actor, right? `actorFor` is fine …

Do you mean Spring would call actorFor on the path or would it be done in code?

   class MyActor(@ActorRef("/user/well/known/service") wellKnownService: ActorRef) { … }

Which isn't to say that I'm super pro-Spring configuration for everything. Probably wiring up an entire actor supervision hierarchy with Spring would be impossible anyway since actor initialisation will often involve asynchronous stuff like message passing. Not everything can be handled with DI at construction. But Spring is possibly good for the simple DI at construction case.

We should first focus on viewing an actor system (or actor tree) as something which interacts with a DI container “as a whole”, i.e. the internal structure is fixed. There is enough to be done here: injecting beans into actors and exposing the services of the actor system to other beans. Let us start with that part.

Injecting beans into actors: yes!

Exposing the services of the actor system to other beans: what did you have in mind here? I think users would probably want to access a few ActorRefs at whatever well-known locations form the actor system's API.

Yes, exactly.

OK. I'll have a think about that.

I sense there may be object creation ordering issues since some actors will depend on Spring beans for DI, some actors will be created independently, but some Spring beans will depend on those actors. Possibly could be worked around by using Futures/Promises… or by letting Spring create any actors it needs. ;)

First I'll just get the DI into actors stuff working though.

Cheers

Rich

[√iktor Ҡlang]

On Mon, Mar 11, 2013 at 11:16 AM, Rich Dougherty <ri...@rd.gen.nz> wrote:

On Mon, Mar 11, 2013 at 10:10 PM, Roland Kuhn <goo...@rkuhn.info> wrote:

To illustrate my technical point: an actor which accepts an injected child would only know how to deal with that child’s failures if those failure characteristics were part of the injection contract. Until we can express this notion I would not want to go in that direction, even though—as I said—I agree that it can be very useful.

If the scope was configured as 'singleton' then the actor would currently be created outside the actor somewhere, probably under "/user".

But that is exactly what we don't want, as it creates dysfunctional supervision trees :/

 

If it was configured as 'actor' then the actor would be created as a child of the current actor, with whatever supervision implications. It is identical to context.actorOf(Props(SpringHelper.createActor("x"))) in the actor's constructor.

But good points. Probably the singleton-ish path is what we're more interested in, especially so that we can provide these singleton actors to other beans so they can interface with the actor system.

"Configurable", to my mind, would probably mean a pair of configurations: a production configuration (which is carefully designed) and a unit-testing configuration (with mock/probe actors). This is IMO pretty much the same way as we often suggest people accept ActorRefs in Actor constructors so that they can mock the actors when testing. Nothing too fancy, just some annotations/XML vs the code approach we already recommend.

   class MyActor(@ActorRef wellKnownService: ActorRef) { … }

But this is the benign kind of looking up another actor, right? `actorFor` is fine …

Do you mean Spring would call actorFor on the path or would it be done in code?

   class MyActor(@ActorRef("/user/well/known/service") wellKnownService: ActorRef) { … }

Which isn't to say that I'm super pro-Spring configuration for everything. Probably wiring up an entire actor supervision hierarchy with Spring would be impossible anyway since actor initialisation will often involve asynchronous stuff like message passing. Not everything can be handled with DI at construction. But Spring is possibly good for the simple DI at construction case.

We should first focus on viewing an actor system (or actor tree) as something which interacts with a DI container “as a whole”, i.e. the internal structure is fixed. There is enough to be done here: injecting beans into actors and exposing the services of the actor system to other beans. Let us start with that part.

Injecting beans into actors: yes!

Exposing the services of the actor system to other beans: what did you have in mind here? I think users would probably want to access a few ActorRefs at whatever well-known locations form the actor system's API.

Yes, exactly.

OK. I'll have a think about that.

I sense there may be object creation ordering issues since some actors will depend on Spring beans for DI, some actors will be created independently, but some Spring beans will depend on those actors. Possibly could be worked around by using Futures/Promises… or by letting Spring create any actors it needs. ;)

First I'll just get the DI into actors stuff working though.

Cheers

Rich

--

You received this message because you are subscribed to the Google Groups "Akka Developer List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Viktor Klang
Director of Engineering

Typesafe

Twitter: @viktorklang