I must correct it. The problem occurs even if i use the proxy in a normal
way:
if (pProxyResult is ITaskToo)
{
((ITaskToo)pProxyResult).doStartExt();
}
So, if i can not call Proceed() on the methods from the ITaskToo Interface,
how am I able to intercept any method from
an additional interface? Is there a way?
2009/6/28 Belvasis <[email protected]>
> 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
-~----------~----~----~----~------~----~------~--~---
