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.
