Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 11:20
    IgorFedchenko commented #3973
  • 11:20
    IgorFedchenko commented #3973
  • 11:18
    IgorFedchenko commented #3973
  • 10:47
    IgorFedchenko synchronize #3973
  • 10:13
    valdisz commented #3921
  • Oct 21 15:57
    Aaronontheweb closed #3877
  • Oct 21 15:57
    Aaronontheweb commented #3877
  • Oct 21 15:56

    Aaronontheweb on dev

    Persistence TestKit documentati… (compare)

  • Oct 21 15:56
    Aaronontheweb closed #3889
  • Oct 21 07:27
    dependabot-preview[bot] labeled #3999
  • Oct 21 07:27

    dependabot-preview[bot] on nuget

    Bump FluentAssertions from 4.14… (compare)

  • Oct 21 07:27
    dependabot-preview[bot] opened #3999
  • Oct 20 17:25
    valdisz synchronize #3889
  • Oct 20 17:17
    valdisz synchronize #3889
  • Oct 20 15:44
    valdisz synchronize #3889
  • Oct 20 09:22
    ismaelhamed commented #3863
  • Oct 19 23:39
    valdisz synchronize #3889
  • Oct 19 23:08
    edvinasz commented #2947
  • Oct 19 13:36
    Aaronontheweb commented #3973
  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3995
Arjen Smits
@Danthar
Do you guys make .Net 4 builds ?
ah, nuget says nope.
So in short: No known issues, but its not officially supported.
ugh! I hate this: https://skillsmatter.com/skillscasts/4081-greg-young-4081 "Because of its privacy settings: This video cannot be played here"
Arjen Smits
@Danthar
@nvivo the new routing docs are great. But could use some extension on what resizers are and how they work.
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