Great stuff, thanks a lot. I will post my thoughts absout subcontainers on the list when I have thought it over.
Now I really need to switch focus from this for a while, my girlfriend told me that I had said something about containers in my sleep this morning :) Thanks for your patience 2010/9/21 Krzysztof Koźmic <[email protected]> > Ok, in the meantime if you don't want to change your solution much I > committed a change that will let you override a method in > DefaultDependencyResolver to change its behavior to the way it was in 1.0.3 > so that you'll be able to propagate the inline dependencies down the > resolution chain. > > It will be part of v2.5.1 which I'm just preparing and it should be out in > a couple of hours. > > I'm still more than happy to hear your thoughts about sub-containers > support for v3. No doubt it will have to be seriously rethought and since > you're using them in real app I really am interested in your feedback here. > cheers, > Krzysztof > > > > > On 21/09/2010 8:34 PM, John Gunnarsson wrote: > > I Guess a child container concept as in how it will work in 3.0 would > resolve (haha) all my problems. > Don't have in depth knowledge of how other containers could solve > contextual dependencies, so I will have a look, > maybe there are some clever solutions that could inspire the subcontainer > redesign in 3.0..... > > > > > 2010/9/21 John Gunnarsson <[email protected]> > >> Today a realm is a composition of a container, realm specific >> configuration (connection strings etc) and a realmid. >> >> There is a world concept aswell, simply containing a list of all realms. >> The world also has a container, containing services etc. >> From the world I can locate a realm by realmid. >> >> rest requests is not the only way of starting a rootservice resolve, >> we got windows services that could be targeted to perform some task >> (aggregate data from a rdbms to a mongo instance for examle) for a specific >> realm (resort), where the reamid could come from a config file. >> >> >> >> >> >> 2010/9/21 Krzysztof Koźmic <[email protected]> >> >>> ok, let's step back a little. >>> How do you use the realm id and the container exactly? >>> >>> >>> On 21/09/2010 7:19 PM, John Gunnarsson wrote: >>> >>> Well, for the cases where everyting starts with a request, that would >>> be a viable solution. >>> >>> But for the other cases where we rather perform something on each realm >>> (and aggregate the result from each realm), the request cannot be the thing >>> used to determine the contex.... >>> >>> >>> >>> 2010/9/21 Krzysztof Koźmic <[email protected]> >>> >>>> OK, >>>> >>>> I'm guessing you could use handlerselectors for this. >>>> Since as you mentioned the id is passed in the request you can get >>>> access to the current request in the selector and get the id and perform >>>> the >>>> selection logic there. >>>> >>>> thoughts? >>>> >>>> Krzysztof >>>> >>>> >>>> On 21/09/2010 7:06 PM, John Gunnarsson wrote: >>>> >>>> The site is a portal for several resorts. >>>> Each resort has it's own database and other specific resources. >>>> >>>> As a user you could either search for available available accomodation >>>> in one resort, >>>> or you could search for available accomodation for all resorts. >>>> >>>> So, requests can be realm (resort) specific, where we got a realmId >>>> (that comes as a rest req. param) that determines in which >>>> realm to resolve a specific component. (today we locate the realm for >>>> the realmId, and uses it's ioc container to resolve all realmspecific >>>> stuff) >>>> >>>> For the situation where we would like to invoke same logic for several >>>> realms, (aggregate all available accommodation for all realms into one >>>> search result) >>>> we simply loop all realms and perform some action on each realm where >>>> the action will get the correct dependencies injected into them via the >>>> realm. >>>> >>>> Ehh, well, hope I have clarified something, or did I make it worse? :) >>>> It's kind if a special case, we are integrating with an existing system. >>>> >>>> >>>> >>>> >>>> >>>> 2010/9/21 Krzysztof Koźmic <[email protected]> >>>> >>>>> There's no way to pass any parameters to handlerselectors. >>>>> What are these realm things? How do you decide what realm you're in at >>>>> any given point in time? >>>>> >>>>> >>>>> On 21/09/2010 5:05 PM, John Gunnarsson wrote: >>>>> >>>>>> Okay, >>>>>> >>>>>> Well its almost like a multi tenancy situation. In some situations the >>>>>> application Will handle operations on several realms, so i cant rely >>>>>> on one thread = same realm or something like that. >>>>>> >>>>>> So how do i provide the context? Can i pass some kind of context at >>>>>> resolvetime that the IHandlerSelector can use for its decition? >>>>>> >>>>>> >>>>>> >>>>>> On Tuesday, September 21, 2010, Krzysztof Koźmic >>>>>> <[email protected]> wrote: >>>>>> >>>>>>> From what I understand what you call realm is usually called a >>>>>>> tenant. >>>>>>> >>>>>>> In general Windsor's solution for multi tenancy is to have one >>>>>>> container with all the components (that would mean you'd register all >>>>>>> your >>>>>>> ISessionFactories) and then use IHandlerSelector to pick the one that is >>>>>>> needed. >>>>>>> >>>>>>> 2010/9/21 quo<[email protected]> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I would like some advice from you guys regarding contextual >>>>>>> dependencies >>>>>>> >>>>>>> So my case looks like this, I got a bunch on components registered in >>>>>>> my container (transients) >>>>>>> In the applicaton i got something that I call realms. Each realm got >>>>>>> it's own database (nhibernate ISessionFactory), a mongo session >>>>>>> factory etc. etc. >>>>>>> >>>>>>> Usually i want to resolve a component within the context of a realm, >>>>>>> so for example, I expect to have the correct session factory injecten >>>>>>> into my repositories etc. >>>>>>> >>>>>>> The solution that I have today is to have one Ioc container for each >>>>>>> realm, and register all transients in every realms container, >>>>>>> additionally to register diffrent singelton instances of the >>>>>>> sessionfactory etc in each realm. >>>>>>> >>>>>>> My prefered solution would be something like having one container to >>>>>>> register all my transients in (all common components, only registered >>>>>>> once), and depending on my context somehow provide additional >>>>>>> dependencies like sessionfactory etc. >>>>>>> >>>>>>> Initially a childcontainer per realm (to be used as a context where I >>>>>>> could register sessionfactories etc) seemed like my new best friend, >>>>>>> but unfortunately that didn't work out: >>>>>>> http://issues.castleproject.org/issue/IOC-116 >>>>>>> >>>>>>> My next try was do provide my contextual dependencies via a >>>>>>> Dictionary<Type,object> at resolve time, but that didn't work >>>>>>> either: >>>>>>> http://issues.castleproject.org/issue/IOC-219 >>>>>>> >>>>>>> >>>>>>> My design goal is that my components should not be aware that there >>>>>>> exists several realms, they should just depend on the fact that all >>>>>>> underlying dependencies is correctly resolved. >>>>>>> >>>>>>> How do you solve contextual dependencies? >>>>>>> Can't find any good info about someone else having the same >>>>>>> requirement's, have I screwed up royal in my design? >>>>>>> >>>>>>> >>>>>>> //John >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Castle Project Users" group. >>>>>>> To post to this group, send email to >>>>>>> [email protected]. >>>>>>> To unsubscribe from this group, send email to >>>>>>> [email protected]<castle-project-users%[email protected]> >>>>>>> . >>>>>>> For more options, visit this group at >>>>>>> http://groups.google.com/group/castle-project-users?hl=en. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Castle Project Users" group. >>>>>>> To post to this group, send email to >>>>>>> [email protected]. >>>>>>> To unsubscribe from this group, send email to >>>>>>> [email protected]<castle-project-users%[email protected]> >>>>>>> . >>>>>>> For more options, visit this group at >>>>>>> http://groups.google.com/group/castle-project-users?hl=en. >>>>>>> >>>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Castle Project Users" group. >>>>> To post to this group, send email to >>>>> [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> [email protected]<castle-project-users%[email protected]> >>>>> . >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/castle-project-users?hl=en. >>>>> >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Castle Project Users" group. >>>> To post to this group, send email to >>>> [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]. >>>> For more options, visit this group at >>>> http://groups.google.com/group/castle-project-users?hl=en. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Castle Project Users" group. >>>> To post to this group, send email to >>>> [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]<castle-project-users%[email protected]> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/castle-project-users?hl=en. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Castle Project Users" group. >>> To post to this group, send email to >>> [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/castle-project-users?hl=en. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Castle Project Users" group. >>> To post to this group, send email to >>> [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<castle-project-users%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/castle-project-users?hl=en. >>> >> >> > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Users" group. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-users?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Users" group. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to > [email protected]<castle-project-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/castle-project-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
