Attempt to illustrating my thinking. - You have component A on Windsor, transient - First time you request it, a custom logging facility attached a logger interceptor - Second time, atm facility was present, and attached the atm interceptor
If the selector were defined in proxy generation time - which would be much more efficient - it would have to deal with this situation. That's what led me to move selection in execution time.. On Tue, Dec 23, 2008 at 4:03 AM, Jonathon Rossi <[email protected]> wrote: > I like the "ref IInterceptors[]". The comments I made about needing the > FieldInfo was to do with reading/writing the interceptors from the generated > field, but this isn't needed since you are passing a ref of the field to > AbstractInvocation. > > Hammett said the following: >> >> re-proxying a type for different scenario (logging + atm) > > I thought he was referring to the ability of getting the interceptor > selector to be called again so you can reselect the interceptors the a > proxy. However, I probably misunderstood what he meant by this. > > On Tue, Dec 23, 2008 at 6:11 PM, Krzysztof Kozmic <[email protected]> > wrote: >> >> Hi >> >> As for your concerns. >> >> 1. AbstractInvocation whould _not_ know about the field. The >> AbstractInvocation's code could be similar to this: >> >> protected AbstractInvocation( >> object target, object proxy, IInterceptor[] interceptors, >> Type targetType, MethodInfo targetMethod, object[] >> arguments, >> ref IInterceptor[] methodInterceptors, IInterceptorSelector >> selector) >> { >> Debug.Assert( selector != null, "if this .ctor is called >> selector must exist" ); >> if (methodInterceptors == null) >> { >> methodInterceptors = selector.SelectInterceptors( >> targetType, targetMethod, interceptors ) ?? new IInterceptor[0]; >> } >> >> this.proxy = proxy; >> this.target = target; >> this.interceptors = methodInterceptors; >> this.targetType = targetType; >> this.targetMethod = targetMethod; >> this.arguments = arguments; >> } >> >> all AbstractInvocation knows about is that it gets a ref IInterceptor[] >> parameter. I think it's cleaner than passing whole cache, and then >> havign to do lookup. >> >> 2. Why would we want to clean the cache? Can you give an example of a >> scenario that would require that? >> 3. I don't think I understand the last part. The one about using >> reflection to get FieldInfo. Are you still referring to the clear cache >> scenario? >> If not, and you're referring to passing methodInterceptors to generated >> type derived from AbstractInvocation, I don't understand why you need >> FieldInfo for? >> You don't need to pass fieldInfo, but field reference. So the field >> could be created and only used in the method that generates overriden >> method. >> >> Krzysztof >> >> >>> [email protected] 2008-12-23 03:17 >>> >> As Krzysztof has mentioned the cache has to be per instance. I >> mentioned >> earlier just using a dictionary in the proxy because I thought it would >> keep >> the proxy neater, but having a field for each method may be better (I'm >> not >> sure how much faster it would make it). However, it means that the >> AbstractInvocation needs to write to each field instead of being passed >> a >> simple cache object. Clearing the cache has to know about each field >> for >> each MethodInfo, but that might not matter depending on where the >> clear >> cache method is provided. If we went with an interceptors field for >> each >> method wouldn't that mean that the code generation of the method would >> have >> to be changed to pass this field to the IInvocation, otherwise you have >> to >> use reflection to get the FieldInfo (which could be cached but >> complicates >> things more)? >> >> >> 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. >> >> >> > > > > -- > Jonathon Rossi > > > > -- Cheers, hammett http://hammett.castleproject.org/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
