Ayende Rahien pisze: > Ideally, just expose an event such as HandlerNotfound With ability to provide it before throwing an exception? That would be a briliant idea. This would basically be a much more lightweight version of what I proposed in my first post in this thread. +1 on that
Krzysztof > > The problem is that we work with handlers, and I don't think you would > want that > > 2008/12/10 Craig Neuwirt <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > > 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] > <mailto:[EMAIL PROTECTED]>> > > Not right now, but that might be a great idea > > 2008/12/10 Craig Neuwirt <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> > > Ayende, > > > Are you planning to expose events on the NamingSystem > when component not resolved? > > 2008/12/10 Ayende Rahien <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> > > > > 2008/12/10 Krzysztof Kozmic <[EMAIL PROTECTED] > <mailto:[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] <mailto:[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] > <mailto:[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 -~----------~----~----~----~------~----~------~--~---
