Hi, I got a bit lost in your post :) but I will point you some things that may be useful (or not at all).
I've wrote a custom contextual lifestyle.. the info is here: http://blog.schuager.com/2008/11/custom-windsor-lifestyle.html (I'm not happy with this implementation) <http://blog.schuager.com/2008/11/custom-windsor-lifestyle.html>Then I've continue doing some experiments and reach something that pass these tests (and others): http://gist.github.com/320996 If you are interested in this just ping me. On Wed, Mar 3, 2010 at 2:26 PM, Alex Davidson <[email protected]>wrote: > Hi, > > I'm not sure how to accomplish this, but I suspect it will eventually > involve lifestyles and child kernels: > > interface IIndexSchema<TKey> { } > > interface IIndex {} > interface IIndex<TKey> {} : IIndex {} > interface IIndex<TKey, TSchema> : IIndex<TKey> where TSchema : > IIndexSchema<TKey> > { > TSchema Schema {get;} > } > > interface IIndexFactory > { > IIndex<TKey, TSchema> Create<TKey, TSchema>(); > } > > interface ITask<TKey> { } > > interface ITaskQueue<TKey> > { > void Enqueue<TTask>() where TTask : ITask<TKey> > } > > Each IIndex<TKey, TSchema> should be a singleton. Its implementation > depends on many other components; these should be instantiated once > for each IIndex<TKey, TSchema> (and may depend on each another too). > One of IIndex's dependencies is ITaskQueue. It must be able to resolve > TTask, injecting component instances from its IIndex's scope where > possible. > > What I do right now is create a child kernel for each TSchema, > registering certain components in it (including the IIndex<TKey, > TSchema>, just to make things fun), then registering the IIndex<TKey, > TSchema> in the parent kernel/container too (currently done by > delegating to that TSchema's child kernel via a factory method). > > And now I'd like to be able to add additional interfaces with TSchema > type arguments alongside IIndex<TKey, TSchema> in the parent > container, and have them get per-TSchema instances where possible > too... > > So...would this be better handled with a LifestyleManager of some > sort? > > I'm guessing it'd be necessary to gather all the generic arguments > from the service being instantiated (including gen args of its gen > args if present) to find something matching a TSchema. Then would I > need to set that in the CreationContext for the component? Would that > information still be present when resolving subdependencies too? If > they're set to be per-TSchema they'd have to be selected based upon > the schema of whatever depends on the thing that depends on them, etc. > There needs to be a way of injecting context into a component instance > too (ITaskQueue<TKey>, specifically), such that it can ask for an > ITask<TKey> implementation and get it resolved with components for its > owning TSchema if possible. Could that be done by providing > ITaskQueue<TKey> with something akin to ITypeResolver<TSchema> to > capture the context, or is there a better way? > > Am I right about any of this, or am I heading down another blind > alley? The Windsor docs on implementing facilities and lifestyles seem > to be rather sparse, or maybe I'm looking in the wrong place. For > instance, what is the lifecycle of a CreationContext? > > > Thanks! > > Alex Davidson > > -- > 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.
