No, it is false. On Sun, Jun 28, 2009 at 11:23 AM, Belvasis <[email protected]>wrote:
> So in the end, my conclusion from some days ago was not that false: > > "I thought it would be completely transparent for the user of the object if > it i proxied or not. This is true if you work with the public signature of > the object, but not if you use reflection as far as i can see." > > > 2009/6/28 Ayende Rahien <[email protected]> > > Belvasis,DP will direct all calls to the extension interfaces to the >> interceptor. You cannot call Proceed on those methods. >> You need to recognize and detect them. >> >> >> On Sat, Jun 27, 2009 at 6:15 PM, Belvasis <[email protected]>wrote: >> >>> Hm i don't understand this. In the interceptor i don't want to know >>> anything about additional interfaces. And as far as i can see, i'm not able >>> to bring in the target object, if i use CreateClassProxy. If i try to Add >>> it as Mixin, an exception it thrown because the >>> proxy and the mixing are both implementing the same interface. But >>> anyway, i did it now simply with >>> >>> CreateInterfaceProxyWithTargetInterface(typeof(ITask), >>> i_pTask.GetType().GetInterfaces().*Where(x => !(x == >>> typeof(ITask))).ToArray()*, i_pTask, >>> >>> new ProxyGenerationOptions(), new TaskInterceptor()) as ITask; >>> >>> So the *shouldfind_* test are running with success now, becaus the >>> doStart() method has no duplicates. But the problem with the endless >>> loop is still there... >>> >>> >>> >>> 2009/6/27 Ayende Rahien <[email protected]> >>> >>>> You need to keep track of the mixin interfaces in the interceptor, you >>>> can do that since you create both of them at the same time >>>> >>>> >>>> On Sat, Jun 27, 2009 at 11:36 AM, Belvasis >>>> <[email protected]>wrote: >>>> >>>>> Yes I know, but i have no other possibility in my current case. As i >>>>> wrote in another thread, if there where something >>>>> like *CreateClassProxyWithTarget* i had no need for this. This means >>>>> creating a proxy for an existing object >>>>> without the knowledge of specific interfaces: >>>>> >>>>> Task pTask = TaskRegistry.createTask(pTask); >>>>> >>>>> ... >>>>> clas TaskRegistry >>>>> { >>>>> Task createTask(Task i_pTask) >>>>> { >>>>> return CreateClassProxyWithTarget(i_pTask.GetType(),...); >>>>> } >>>>> } >>>>> >>>>> So i could intercept all methodes decorated with specific attributes >>>>> etc. >>>>> >>>>> 2009/6/27 Ayende Rahien <[email protected]> >>>>> >>>>> You are supposed to handle mixin interfaces differently >>>>>> >>>>>> >>>>>> On Fri, Jun 26, 2009 at 12:59 AM, Belvasis <belvasis.de@ >>>>>> googlemail.com> wrote: >>>>>> >>>>>>> So, finally i created some tests. With the *shouldfind_method* test >>>>>>> i'm not sure if it is a bug or not. >>>>>>> The problem here is that the proxy has two methods with the same name >>>>>>> and signature. This is logic since >>>>>>> in the tested case one interface is given twice to the >>>>>>> ProxyGenerator. I'm just wondering why this doesn't result >>>>>>> in an exception. With the real case the problem is, it is not >>>>>>> startable with NUnit, Gallio etc. They both crashed. >>>>>>> Hope you can find something... >>>>>>> >>>>>>> >>>>>>> 2009/6/25 Belvasis <[email protected]> >>>>>>> >>>>>>> Yes i'll do it later this evening, i'm on travel right now >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Am 25.06.2009 um 16:45 schrieb Ayende Rahien <[email protected]>: >>>>>>>> >>>>>>>> That most definitely should not.Can you create a test case? >>>>>>>> >>>>>>>> On Thu, Jun 25, 2009 at 5:41 PM, Belvasis < <http://belvasis.de> >>>>>>>> belvasis.de@ <http://googlemail.com>googlemail.com> wrote: >>>>>>>> >>>>>>>>> Now i'm confused ;) Did you think i called the MethodInfo.Invoke >>>>>>>>> from inside the intercepto? No, no i didn't. That this results in an >>>>>>>>> endless >>>>>>>>> loop is clear. I did simply: >>>>>>>>> Obj = CreateInterfacProxyWithTarget >>>>>>>>> pMethod.Invoke(obj...) >>>>>>>>> >>>>>>>>> And Inside the interceptor: >>>>>>>>> >>>>>>>>> ... >>>>>>>>> If( check(...)) >>>>>>>>> invocation.proceed() >>>>>>>>> >>>>>>>>> This leads to a StackOverflow... >>>>>>>>> >>>>>>>>> Am 25.06.2009 um 16:09 schrieb Ayende Rahien < <[email protected]> >>>>>>>>> [email protected]>: >>>>>>>>> >>>>>>>>> It _is_, from the OUTSIDE.You are calling this from the >>>>>>>>> intereceptor! >>>>>>>>> >>>>>>>>> On Thu, Jun 25, 2009 at 5:03 PM, Belvasis < >>>>>>>>> <http://belvasis.de><http://belvasis.de> >>>>>>>>> belvasis.de@ <http://googlemail.com> <http://googlemail.com> >>>>>>>>> googlemail.com> wrote: >>>>>>>>> >>>>>>>>>> No thats not what i want or need :( I thought it would be >>>>>>>>>> completely transparent for the user of the object if it i proxied or >>>>>>>>>> not. >>>>>>>>>> This is true if you work with the public signature of the object, >>>>>>>>>> but not if >>>>>>>>>> you use reflection as far as i can see. I wanted the developer to >>>>>>>>>> call >>>>>>>>>> something like TaskRegistry.invokeTask("taskDef"). In the end this >>>>>>>>>> builds a >>>>>>>>>> stateless Task object. Every method of the Task can be decorated >>>>>>>>>> with an >>>>>>>>>> TaskImplementor("taskDef") Attribute and those methods should be >>>>>>>>>> intercepted >>>>>>>>>> to check availability, permission etc., if the are invoked. So i >>>>>>>>>> have to use >>>>>>>>>> reflection for it. Maybe i have to think about other ways to do this. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Am 25.06.2009 um 10:01 schrieb Ayende Rahien >>>>>>>>>> <<[email protected]><[email protected]> >>>>>>>>>> [email protected]>: >>>>>>>>>> >>>>>>>>>> Yes, that is what you want, no? >>>>>>>>>> >>>>>>>>>> On Thu, Jun 25, 2009 at 10:50 AM, Belvasis < >>>>>>>>>> <http://belvasis.de><http://belvasis.de><http://belvasis.de> >>>>>>>>>> belvasis.de@ <http://googlemail.com> >>>>>>>>>> <http://googlemail.com><http://googlemail.com> >>>>>>>>>> googlemail.com> wrote: >>>>>>>>>> >>>>>>>>>>> But if i invoke the method on the DynProxyGetTarget() - object it >>>>>>>>>>> bypasses the interceptor, or do Ido something wrong? On the other >>>>>>>>>>> hand >>>>>>>>>>> what you say means, you have alwys to know if an object is a >>>>>>>>>>> proxy or not. Is this wanted? >>>>>>>>>>> >>>>>>>>>>> Thanks and regards >>>>>>>>>>> >>>>>>>>>>> Am 25.06.2009 um 02:01 schrieb Ayende Rahien >>>>>>>>>>> <<[email protected]><[email protected]><[email protected]> >>>>>>>>>>> [email protected]>: >>>>>>>>>>> >>>>>>>>>>> That is the expected behavior.Invoking a method using Invoke >>>>>>>>>>> will mean that you get back to the interceptor. >>>>>>>>>>> The workaround you specified is how this should work. >>>>>>>>>>> >>>>>>>>>>> On Thu, Jun 25, 2009 at 2:55 AM, Belvasis < >>>>>>>>>>> <http://belvasis.de><http://belvasis.de><http://belvasis.de><http://belvasis.de> >>>>>>>>>>> belvasis.de@ <http://googlemail.com> >>>>>>>>>>> <http://googlemail.com><http://googlemail.com><http://googlemail.com> >>>>>>>>>>> googlemail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> > Hi, >>>>>>>>>>>> > I have the following problem: >>>>>>>>>>>> > I want to invoke a method on a proxy >>>>>>>>>>>> > using MethodInfo.Invoke(...). The method should be >>>>>>>>>>>> intercepted, if the >>>>>>>>>>>> > InterceptorSelector decided to do so. >>>>>>>>>>>> > The problem is, that the Interceptor.Intercept method is >>>>>>>>>>>> called in >>>>>>>>>>>> > an endless loop, if invocation.Proceed is called Inside the >>>>>>>>>>>> > interceptor. Anyone an idea why this happend? If i invoke the >>>>>>>>>>>> > corresponding MethodInfo of the DynProxyGetTarget() - object, >>>>>>>>>>>> it >>>>>>>>>>>> > works as expected. >>>>>>>>>>>> > >>>>>>>>>>>> > Thanks >>>>>>>>>>>> > Belvasis >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
