TypedFactoryInterceptor doesn't call Proceed() on the invocation

[Rory Plaire]

Greetings -

 

I'm exploring using another invocation in the call to a typed factory. I can put my invocation before the TypedFactoryInterceptor, but not after, since TypedFactoryInterceptor doesn't call Proceed(). I can see why not calling Proceed perhaps in the case of a Release or a Dispose method, but not in the case of a Resolve method.

 

Is this just an oversight or was there a conscious decision not to proceed after the typed factory resolution?

 

-rory

[Krzysztof Koźmic]

of course it doesn't. There's no implementation to proceed to

> --
> You received this message because you are subscribed to the Google
> Groups "Castle Project Development List" group.
> To post to this group, send email to
> castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to
> castle-project-d...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.

[Rory Plaire]

2011/7/20 Krzysztof Koźmic <krzyszto...@gmail.com>

of course it doesn't. There's no implementation to proceed to

 

Indeed, of course... but this also precludes chaining subsequent interceptors. However, doesn't the ExtendedHandler take care of not needing an actual instance to proceed to?

[Krzysztof Koźmic]

As far as other interceptors are concerns the factory interceptor _is_ the implementation. You can put other interceptors before the factory one.

Extended handler has no role in that process, it does something else altogether.

Why would you want to put anything past the factory interceptor?

Krzysztof

[Rory Plaire]

As to why: here is the question I posted on SO -

http://stackoverflow.com/questions/6772484/castle-windsor-passing-a-dependency-through-2-typed-factories

 

Summary: I want to create a typed factory from another typed factory but I want to add a dependency to the resolution context of the 2nd typed factory.

 

I wanted to put an interceptor after the resolution of the 1st typed factory in order to contribute this dependency to the context.

 

As to ExtendedHandler - it appears that the typed factory uses this as the handler to invoke the chain of invocations, which is why I thought it would work fine to just add another after the resolution was done in the typed factory interceptor, if the interceptor just called Proceed().

 

-r

2011/7/21 Krzysztof Koźmic <krzyszto...@gmail.com>

[Krzysztof Koźmic]

Hmmm

that is interesting. In general, Typed Factories were meant to be stateless, I can see value in this scenario, just I'm not sure what would be an elegant way to support it.
Why don't you just make the first factory an actual class, and for the second one use a typed factory?

[Rory Plaire]

Yea, I thought of making the 1st factory a concrete class, but I couldn't come up with an elegant way to have it resolve the 2nd factories from the container when the CreateFactory method is called.

 

If you have a thought on a resolution approach, I'd love to hear it. I'm going to try hacking around with adding some kind of statefullness to the typed factory, and see if it's worth a closer look.

 

-r

2011/7/22 Krzysztof Koźmic <krzyszto...@gmail.com>