Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 14:40
    cptjazz synchronize #3974
  • 14:07
    cptjazz opened #3974
  • 08:30
    ismaelhamed commented #3937
  • Oct 12 15:50
    IrvinDominin opened #127
  • Oct 11 18:21
    Aaronontheweb commented #3973
  • Oct 11 18:20
    Aaronontheweb commented #3937
  • Oct 11 18:16
    Zetanova commented #3937
  • Oct 11 18:11
    Zetanova commented #3937
  • Oct 11 15:09
    Aaronontheweb commented #3937
  • Oct 11 15:08
    Aaronontheweb commented #3937
  • Oct 11 14:36
    Aaronontheweb commented #3973
  • Oct 11 01:00
    Horusiath commented #3057
  • Oct 10 20:02
    IgorFedchenko synchronize #3973
  • Oct 10 19:59
    IgorFedchenko synchronize #3973
  • Oct 10 19:58
    IgorFedchenko commented #3973
  • Oct 10 19:53
    IgorFedchenko opened #3973
  • Oct 10 14:04
    stijnherreman commented #3057
  • Oct 10 13:54
    Aaronontheweb commented #3970
  • Oct 10 13:54
    Aaronontheweb synchronize #3970
  • Oct 10 10:10
    Zetanova commented #3937
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?
Arjen Smits
@Danthar
I think @jcwrequests already explored this route. I remember him saying something along the lines: Not possible due to inner workings of Akka or something like that.
Natan Vivo
@nvivo
actually, it's not possible because that involves changing the akka dll to know about this.
Arjen Smits
@Danthar
I have no idea if that that is the case.
Natan Vivo
@nvivo
if you change the right bits, it's possible to make akka cook hamburguers
=)
Looking at the Props, it works almost like a DI resolver
So, in theory it could decide "i can create this type or I'll delegate this to someone who can (the DI)"
but I'm not sure if this is a good approach
currently, the DI is registered inside the actor system. So, maybe the actor system could decide that...
Arjen Smits
@Danthar
Well. Make an issue for it =) Better to have this discussion in the tracker then here anyway. Because then it will be documented.
Because we had this discussion, about integration the DI system. Multiple times now ;)
Natan Vivo
@nvivo
yeah, I'm trying to understand if this is possible before opening a ticket
Nikita Tsukanov
@kekekeks

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

Just wrap your ActorRef in something that implements IDisposable and kills the actor after being disposed

interface IDisposableActor<T> : IDisposable
{
    ActorRef Actor{get;}
}

class DisposableActor<T> : IDisposableActor<T>
{
    public ActorRef Actor {get; private set;}
    public DisposableActor()
    {
          Actor = ActorSystem.ActorOf<T>();
    }
    public void Dispose()
    {
         Actor.Tell(oisonPill.Instance, ActorRef.NoSender);
    }
}
Roger Johansson
@rogeralsing
Im not sure i follow, its not the actors that are injected, its dependencies into actors. So the actor ref would never be wrapped in anything in the di
Nikita Tsukanov
@kekekeks
I think that @Danthar tries to inject ActorRef in ASP.NET controller
And have it's lifetime managed by DI-container
Roger Johansson
@rogeralsing
Oh, that is not supported, you inject into actors, not actors into other stuff
Nikita Tsukanov
@kekekeks
It shouldn't be ever supported by Akka itself