On Tuesday, May 28, 2013 7:16:04 PM UTC+3, cortex wrote: > > Be carefull with thread-safeness. > > Autofac is scoped container but RSB do not handle scope. I think you > should consider modify autofac bootstrapper to call dispose on IDisposable > object in Release method. Normally IConsumer should be register as > transient (InstancePerDependency). The only thing missing is a > deterministic call to Dispose(). >
Right - at least there should be if (o is IDiposable) then o.Dispose(). In my sample all consumers resolved withing a lifetime scope would be released automatically. > I think you're trying to do some sort of Unit Of Work scope (resolving to > the same instance multiple times during one message processing), that RSB > do not handle by default. It was historically done through the help of a > IMessageModule. > With the help of a ThreadStatic context variable set and unset on > ITransport events, a custom Castle ILifestyleManager could rely on it to > keeps track of message scoped instances. > Wrong - I'm not trying to resolve the same instance of a consumer. Consumers are still registered per dependency. What I'm trying to is automatic disposal of consumers' dependencies in a normal Ioc fashion. Resolving the same instance is just a side effect here. > Do you think this may also be done for Autofac without modifing RSB core > code and introducing autofac specific handling of lifetime in the > DefaultServiceBus Implementation ? > That's not autofac-specific actually. I assume any Ioc supports scopes and any of existing IServiceLocator implementations can be adjusted accordingly. Actually I think that 'per-message-scope' is more logical and suitable, just the same as 'per-request-scope' is now de facto standard of web apps approach. It seems that it's not possible to change only service locator side. DefaultHandler.Resolve returns a resolved consumer object, not a scope. Other solution is clearly client-side: If all dependencies are registered properly (something like 'to be resolved in scope of XConsumer') - probably that would work, but need much additional work on proper registration creation and maintenance. > > For help, I used something like this : http://pastebin.com/NA3gzKPm > Well - I didn't know about modules, thank you - will check, probably that way it's going to work. > > > > 2013/5/28 Mikalai Chaly <nch...@gmail.com <javascript:>> > >> Well - probably in the code that would be more clear. In the github fork >> I made a >> change<https://github.com/nchaly/rhino-esb/commit/5b4ed1e80ab55a9fc1745bef45fcf98082183f11>, >> >> which controls life time as I outlined in the initial post. >> >> >> On Friday, May 24, 2013 4:11:26 PM UTC+3, Corey wrote: >> >>> All of the containers are community supported. I believe the behavior of >>> calling Dispose is the default behavior for both Windsor and StructureMap, >>> and maybe isn't for Autofac? >>> >>> >>> On Fri, May 24, 2013 at 6:17 AM, Mikalai Chaly <nch...@gmail.com> wrote: >>> >>>> Is there a way to control consumers and their dependencies lifetime >>>> scope? >>>> >>>> I have a set of dependencies which is usual for web development: >>>> >>>> - Consumer depends on Service1 and Service2. >>>> - Service1 and Service2 depend on Repository. >>>> >>>> Expected life cycle: >>>> - Repository created >>>> - Service1 created >>>> - Service2 created >>>> - Consumer created >>>> - ..... some processing... >>>> - Consumer disposed >>>> - Service2 disposed >>>> - Service1 disposed >>>> - Repository disposed. >>>> >>>> The results where confusing a little bit. When using autofac >>>> bootstrapper, even Consumer.Dispose is not invoked (it is, when using >>>> CastleBootStrapper). >>>> >>>> So my question is: is this behaviour by design? Are there some plans to >>>> add lifetime control? >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Rhino Tools Dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to rhino-tools-d...@**googlegroups.com. >>>> To post to this group, send email to rhino-t...@googlegroups.**com. >>>> >>>> Visit this group at http://groups.google.com/** >>>> group/rhino-tools-dev?hl=en<http://groups.google.com/group/rhino-tools-dev?hl=en> >>>> . >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>> . >>>> >>>> >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Rhino Tools Dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to rhino-tools-d...@googlegroups.com <javascript:>. >> To post to this group, send email to rhino-t...@googlegroups.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to rhino-tools-dev+unsubscr...@googlegroups.com. To post to this group, send email to rhino-tools-dev@googlegroups.com. Visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
