I need to support WCF stuff that Krzysztof requested so if you have any
details about this possible change, just give me a shout so we are on the
same page.

thanks

2008/12/10 Ayende Rahien <[EMAIL PROTECTED]>

> Not right now, but that might be a great idea
>
> 2008/12/10 Craig Neuwirt <[EMAIL PROTECTED]>
>
>> Ayende,
>>
>>
>>    Are you planning to expose events on the NamingSystem when component
>> not resolved?
>>
>> 2008/12/10 Ayende Rahien <[EMAIL PROTECTED]>
>>
>>>
>>>
>>> 2008/12/10 Krzysztof Kozmic <[EMAIL PROTECTED]>
>>>
>>>>
>>>> How do you plan to support it without changing the kernel?
>>>>
>>>
>>> custom naming sub system, probably
>>>
>>>
>>>>
>>>> 1. If we were to support WCF config, I think it would be reasonable to
>>>> only say to the facility "use the config file" and not register the 
>>>> services
>>>> explicitly.
>>>> Then, with current implementation of the DefaultKernel, we have no way
>>>> of doing this, since Kernel checks its registered components, and if it
>>>> doesnt find one, it throws.
>>>> This all happends before event SubDependencyResolver gets a chance to be
>>>> called.
>>>
>>>
>>> We can extend the naming sub system to look for components in the wcf
>>> config.
>>> That can be done in the facility.
>>>
>>>
>>>>
>>>>
>>>> >  I think we should only raise an error if Abstract and not and
>>>> interface.  It is very reasonable to support only interface registrations.
>>>> 2. I'm not sure it's such a good idea. First, even WCF Contract can be a
>>>> class, not an interface (not that I'm advocating it, but WCF allows it).
>>>> Second, there may be other
>>>> situations where user may want to register virtual component, and deal
>>>> with it in a similar manner to WCF Facility. I think we need an opt-in
>>>> mechanism for that.
>>>>
>>>
>>> agreed, consider the case where I want to do things like IronPython
>>> components.
>>> Actually, my DSL stuff is often used that way.
>>>
>>>
>>>>
>>>> > I think we can do with the existing activator support
>>>> 3. Ayende, can you elaborate a little bit on that?
>>>>
>>>
>>> See my next commit.
>>>
>>>
>>>>
>>>> Cheers,
>>>>
>>>> Krzysztof
>>>>
>>>> >>> [EMAIL PROTECTED] 2008-12-10 15:15 >>>
>>>> I am trying to support this without having to change the kernel.  This
>>>> type
>>>> of support sounds like a job for SubDependencyResolver, but that get
>>>> called
>>>> before the kernel is given a chance to resolve it.  Do you think
>>>> SubDependecyResolver should come last in the resolution strategy?
>>>>
>>>> On Wed, Dec 10, 2008 at 1:05 AM, Krzysztof Koźmic <
>>>> [EMAIL PROTECTED]> wrote:
>>>>
>>>> >  Hi,
>>>> > I wrote about it some time ago in the context of using WCF
>>>> configuration
>>>> > file as sole source of information for resolving WCF components.
>>>> > My idea was to extend the way IKernel resolves components. Right now
>>>> when
>>>> > it does not have a component registered (or we're trying to register
>>>> > asbtract component as you wrote) it throws.
>>>> > Alternatively, to support this kind of scenarios, we might extend it
>>>> (via
>>>> > facility?) that would be called in those situations (i.e. while
>>>> registering
>>>> > otherwise illegal component, or while resolving unregistered
>>>> component).
>>>> > It would require two methods:
>>>> >
>>>> > *bool CanProvide(Type componentType, string name, IKernel
>>>> kernel);//kernel
>>>> > throws when it returns false
>>>> > object Provide(Type componentType, string name, IKernel kernel); //OR
>>>> > IHandler Provide(Type componentType, string name, IKernel kernel, out
>>>> > IHandler[] dependencies);*
>>>> >
>>>> > This is only an initial idea and it would have to be thought through
>>>> to
>>>> > ensure that it easily fits with other aspects of the container.
>>>> >
>>>> > This solution would be IMHO flexible enough to handle I think all of
>>>> WCF
>>>> > needs (incl, not-yet-implemented support for config file), AND would
>>>> easily
>>>> > solve the problem you described.
>>>> >
>>>> > Thoughts?
>>>> >
>>>> >
>>>> > Ayende Rahien pisze:
>>>> >
>>>> > I just applied a patch to detect and give a good error if we are
>>>> trying to
>>>> > register a component whose implementation is abstract. That broke the
>>>> WCF
>>>> > facility, which allow you to register just the interface, and rely on
>>>> the
>>>> > WCF machinery to provide the real implementation.
>>>> > Currently I "fixed" the build by making sure that the test in the code
>>>> > specify an implementation, but considering a common case for the WCF
>>>> client
>>>> > facility, we won't _have_ an implementation.
>>>> > Any suggestions for solving this?
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > >
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>> CONFIDENTIALITY NOTICE
>>>> This message is intended exclusively for the individual or entity to
>>>> which it is addressed. This communication may contain information that is
>>>> proprietary, privileged, confidential or otherwise legally exempt from
>>>> disclosure. If you are not the named addressee, you are not authorized to
>>>> read, print, retain, copy or disseminate this message or any part of it. If
>>>> you have received this message in error, please delete all copies of this
>>>> message and notify the sender immediately by return mail or fax ATSI
>>>> S.A.(+4812) 285 36 04.
>>>> Any email attachment may contain software viruses which could damage
>>>> your own computer system. Whilst reasonable precaution has been taken to
>>>> minimise this risk, we cannot accept liability for any damage which you
>>>> sustain as a result of software viruses. You should therefore carry out 
>>>> your
>>>> own virus checks before opening any attachments.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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 [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-devel?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to