Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 10:41
    Aaronontheweb commented #4097
  • 08:19
    ismaelhamed synchronize #4097
  • 02:22
    kimbyungeun opened #4098
  • Dec 15 19:47

    Aaronontheweb on dev

    TypeExtensions.TypeQualifiedNam… (compare)

  • Dec 15 19:47
    Aaronontheweb closed #4071
  • Dec 15 19:47
    Aaronontheweb closed #3767
  • Dec 15 19:47
    Aaronontheweb labeled #3767
  • Dec 15 19:47
    Aaronontheweb labeled #3767
  • Dec 15 19:47
    Aaronontheweb milestoned #3767
  • Dec 15 19:44
    Aaronontheweb labeled #4097
  • Dec 15 19:44
    Aaronontheweb milestoned #4097
  • Dec 15 13:23
    Aaronontheweb commented #4096
  • Dec 15 13:22
    Aaronontheweb commented #4093
  • Dec 15 13:16
    ismaelhamed commented #4093
  • Dec 15 13:04
    ismaelhamed edited #4097
  • Dec 15 13:04
    ismaelhamed opened #4097
  • Dec 15 12:50
    ismaelhamed commented #4096
  • Dec 15 12:48
    ismaelhamed commented #4096
  • Dec 15 12:05
    Aaronontheweb commented #4096
  • Dec 15 11:43
    ismaelhamed commented #4096
Natan Vivo
@nvivo
@Danthar, I'll take a look at that. Thanks
Arjen Smits
@Danthar
@rogeralsing question. About DI and scopes. Currently the docs say that Actors must not have the singleton scope, since its not supported
However, that implies that other scope types are supported. But I think thats wrong, because as far as i understand it
only the transient scope is supported.
Due to how Akka works with location transparency and the lifetime of actors
but i could be wrong :P so im asking ;)
Roger Johansson
@rogeralsing
You can still remotedeploy DI actors, the DI will occur on the remote system as the DI support is based on actor producers
Assuming the correct config exists on the remote system that is
Natan Vivo
@nvivo
@rogeralsing so DI shouldn't affect remoting or clustering?
Arjen Smits
@Danthar
@rogeralsing Ah I remember reading about that. But that is not what I was referring to.
Roger Johansson
@rogeralsing
I havent tried it our but in theory it should work just fine as the props that are pushed to the remote system only contain the typename for the actor producer
Arjen Smits
@Danthar
lets assume a non-remoting/clustering scenario for now.
lets say you are using an actorsystem in asp.net
Arjen Smits
@Danthar
and you register your actors with an DependencyPerHttpRequest scope
Gerjan
@GerjanOnline
Roger, who are these people?
Roland Kuhn?
Arjen Smits
@Danthar
which would mean that the actors are disposed at the end of an httprequest. What i'm thinking is that this cannot work.
Roger Johansson
@rogeralsing
@GerjanOnline yes, Roland Kuhn (akka lead for typesafe) holding the akka frame there.. no idea who the others are
Gerjan
@GerjanOnline
okay thanks
Roger Johansson
@rogeralsing
@Danthar hmm yes that sounds weird.. I have look that up
Gerjan
@GerjanOnline
i think the java guy is Brian Goetz https://twitter.com/briangoetz
not sure, but thanks
Natan Vivo
@nvivo
@rogeralsing, what prevents us from allowing system/context.ActorOf<ISomeInterface>() using DI internally instead of the context.DI().ActorOf<T>?
Arjen Smits
@Danthar
@rogeralsing I think that any DI scope which effectively takes away lifecycle management from the ActorSystem, are not supported. Because it would mean that an Actor could be disposed without the Actor system being aware of it, or being the one who actually starts the dispose. Which in turn would cause all kinds of wierd stuff. As far as i can tell.
But maybe you guys have some voodoo code to manage those scenario's.
@nvivo nothing. Just that when you do that with Actor types. They wont be initialized properly. I take you mean something like this? :
This message was deleted
 myStaticDiContainer.Resolve<typehere>();
Natan Vivo
@nvivo
not exactly
what I mean is more the semantics than the implementation
imagine I have an actor that requires constructor parameters
today I'm required to create the props with DI or manually, and then pass to ActorOf
this creates 2 different ways to declare exactly the same thing
man.... personally I can explain things much better
Arjen Smits
@Danthar
Oh
I think I know what you mean
Your talking about implicit support for DI. So you don't have to do context.DI().ActorOf<IMyInterface>
and you can simply do this: context.ActorOf<IMyInterface>()
Is that what you mean?
what I mean is: it should be possible to use context/system.ActorOf<T> anywhere and not care about DI
DI is an implementation. The default props resolver could just complain "hey, I cannot resolve this type, it requires parameters", while if you set the DI resolver it would work
Arjen Smits
@Danthar
Ah yep. Thats exactly what I meant just now.
But this is not the first time we are having this particular discussion :P
Natan Vivo
@nvivo
oh, sorry. yes.. that's it =) I was writing in the gist, didn't see your comment
Arjen Smits
@Danthar
np
Natan Vivo
@nvivo
currently, DIExt lives in an external assembly
if only that interface (or some new interface) was moved to Akka, some simple logic could be used inside the actor system and any children to use that automatically
I'm trying to understand if that would break anything. Can you think of something?