:-) Ok, than one last simple question...if i can intercept them but can not
call Proceed, how can I decide if those methods should be executed
or not, if thats my intent?

2009/6/28 Ayende Rahien <[email protected]>

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

Reply via email to