If I remember correctly, it was removed because of the potential to create
very fragile code.That is, you pass a value that only somewhere down the
chain is used. That is almost certainly going to bite you at some point.
You can provide our own ISubDependnecyResolver to resurrect this option,
though.
On Wed, Jun 3, 2009 at 3:49 AM, fhwrdh <fhw...@gmail.com> wrote:
> Indeed, it breaks
> the AdditionalParametersShouldNotBePropagatedInTheDependencyChain test in
> MicroKernelTestCase.cs. So this "feature" appears to have been explicitly
> removed. Perhaps there is another(better) way to do what I need...
> I have a service class (in the DDD sense) that depends on a couple of
> classes that wrap web service calls. These web services all require the
> logged in user's credentials and I've been passing them via a .ctor
> argument. I resolve the service with
> container.Resolve<IMyService>(userCredentialDictionary) and expect the
> credentials to make their way to all the dependent web service wrappers.
>
> Without this ability, is there a common pattern for getting runtime
> arguments to dependencies and sub-dependencies? I see that CreationContext
> implements ISubDependencyResolver. Perhaps that is the extension point I
> need to investigate? Or am I missing something else?
>
> Thanks,
> Franklin
>
>
> On Wed, Jun 3, 2009 at 3:39 AM, Mauricio Scheffer <
> mauricioschef...@gmail.com> wrote:
>
>>
>> That constructor seems to have changed in r5488 in order to fix IOC-
>> ISSUE-123 "Patch for SubDependency Resolution in CreationContext to
>> attempt type conversion."
>>
>> Could you run all the tests against your patched trunk? If all the
>> tests pass please submit the patch to donjon.
>>
>> On Jun 2, 8:13 pm, Franklin Henderson <fhw...@gmail.com> wrote:
>> > I've run into a bit of trouble while upgrading from RC3 to Windsor
>> > 2.0. My application depends on the feature in RC3 that passes an
>> > IDictionary of arguments not only to the component being explicitly
>> > resolved, but also to dependencies and sub-dependencies.
>> >
>> > It appears that this feature no longer works in 2.0? I've been through
>> > the code for r5654 and traced it to a .ctor in the CreationContext
>> > class...
>> >
>> > public CreationContext(Type typeToExtractGenericArguments,
>> > CreationContext parentContext)
>> > : this(parentContext.Handler,
>> parentContext.ReleasePolicy,
>> > typeToExtractGenericArguments, null, null)
>> > {
>> > ...
>> > }
>> >
>> > ...that passes null as the fourth argument to another .ctor instead of
>> > parentContext.additionalArguments. After making that change, the old
>> > behaviour seems to return.
>> >
>> > I'm assuming I'm not the first/only person who took advantage of this
>> > functionality in RC3 and, therefore, not the first to run across this
>> > issue.
>> >
>> > My questions are:
>> >
>> > 1. Has this functionality been purposefully removed in 2.0 in favor of
>> > something new?
>> > 2. If not, is this a bug?
>> > 3. If so, is this a reasonable fix? I've tested it a bit, but not
>> > exhaustively.
>> > 4. if so, what is the best way to share this fix? patch? donjon?
>> > something else?
>> >
>> > If any devs are out there, I have a simple unit test for this also.
>> >
>> > Cheers,
>> > Franklin
>>
>>
>
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To post to this group, send email to castle-project-users@googlegroups.com
To unsubscribe from this group, send email to
castle-project-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en
-~----------~----~----~----~------~----~------~--~---
