hehe, no worries [?] Cheers mate. Krzysztof
W dniu 21 września 2010 20:51 użytkownik John Gunnarsson < [email protected]> napisał: > 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]<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.
<<330.gif>>
