Hi Ayende,

I looked at the IHandlerSelector, and have a semi-working implementation
utilising this, but within Kernel[] the following code:

                                if (!HasComponent(service))
                                {
                                        throw new
ComponentNotFoundException(service);
                                }

...returns false, causing a ComponentNotFoundException. This is because
no component is ever registered, due to the component's config element
not having a 'Type' attribute (service Type is redundant if it will be a
transparent WCF proxy).
If I comment out this line, then all the following code works, using my
handler to generate the channel-factory.

How do I get the naming sub-system to recognise that an IHandler
instance is available to dynamically resolve the component?

Thanks



From: [email protected]
[mailto:[email protected]] On Behalf Of Ayende
Rahien
Sent: Thursday, 6 August 2009 11:08 a.m.
To: [email protected]
Subject: Re: Design questions for resolution of IOC-ISSUE-161

IHandlerSelector is how I would handle this.
You would need to provide an implementation of IHandler that provide
instances via the WCF client support.
Shouldn't be too hard, I think.
On Thu, Aug 6, 2009 at 1:52 AM, Adam Langley <[email protected]>
wrote:

After speaking to Krzysztof Kozmic, this question is directed primarily
to Ayende and Craig Newirt,

I require that Windsor has the ability to resolve component types to a
WCF client endpoint configured in system.servicemodel/client rather than
to a well-known type.
Krzysztof suggested that I ask if anyone has attempted to add the
required extensibility points to the micro-kernel to facilitate this
feature, so that I may build on it to bring it to completion.
Additionally, any suggestions on how this should be implemented would be
greatly appreciated.
Krzysztof believes that before the last resort of throwing
ComponentNotFoundException, subscribed facilities should have the chance
to resolve the component.

After taking a brief look at the code this presents two hurdles.

Firstly, when the configuration is initially built, any components that
do not have a Type attribute are ignored, meaning that the naming
subsystem will never admit knowledge of them.
Secondly, even if the naming subsystem admitted knowledge of the
component, code needs to be added to locate a facility that has taken
responsibility for the type resolution, and delegate the call to
it/them.

There are several decisions around how this feature should 'behave',
what do you think?

Thanks

Adam Langley





--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to