I reverted the behavior to the way it was in v2.1
After giving some more thought I think supporting Eric's scenario is
more important (and common) than being able to override internal
components of the facility and it still is possible anyway.
This will be part of v2.5.1
In the meantime as a workaround I suggest just explicitly adding the
itnerceptor to your subcontainers right after registering the facility:
container.Register(Component.For<TypedFactoryInterceptor>()
.Named(TypedFactoryFacility.InterceptorKey));
I wish that would come up in beta program, not days after the release :(
thanks all
On 26/08/2010 4:52 AM, Vinay Mandy wrote:
As I see it, the change that was made for version 2.5 seems to have
been specifically targeted to improve the typical (and probably most
often occuring) usage of using TypedFactories with a single container.
However, support for this particular corner case of using
TypedFactories from a heirarchy of containers has been broken.
Wouldn't the fix be possible? By looking at the code, it seems that
the TypedFactoryFacility first verifies if the necessary components
have already been registered in the container (including its parent)
before registering them himself. Couldn't it instead verify if they
have already been registered in the container excluding its parent?
Otherwise, if the plan is not to support this corner case, then are we
introducing a usage pattern for those wanting to use child containers?
Can the statement "you should add facilities to a container before
adding it as a child" be generalized to apply for all facilities? If
so, then it would be helpful to include it in the user documentation
on child containers.
--
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.
