aspectsharp-users — Users discussion list

[Aspectsharp-users] Serialization

[hammett <ha...@uo...>]

Hiya,

I was talking to bamboo today and thinking about this problem. One possible 
solution suggested by him relies on the use of FormatterServices.

Henry, can you please check this out?

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett

Re: [Aspectsharp-users] IInvocation.Proxy and IInvocation.InvocationTarget

[hammett <ha...@uo...>]

Hello Deyan,

I'd like to see the code, but I'm having problems downloading the zip file 
now..
I'll check it again tonight. By now, I imagine some tweaks that we can try.

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett


----- Original Message ----- 
From: "Deyan Petrov" <de...@ho...>
To: <asp...@li...>
Sent: Thursday, October 28, 2004 8:48 AM
Subject: Re: [Aspectsharp-users] IInvocation.Proxy and 
IInvocation.InvocationTarget

Re: [Aspectsharp-users] IInvocation.Proxy and IInvocation.InvocationTarget

[Deyan P. <de...@ho...>]

Hi hammett,

Great, thanks a lot for the modification!!! Now it looks really great. I
have currently implemented a project with explicit proxies for lazy-loading,
and I am thinking of replacing them with the more transparent Dynamic
Proxies, that's why I am delving into the stuff...

I did some tests and the results are a little bit strange ... I have changed
the retrieval of the objects, so that they are loaded from the db now. The
full code is here:
http://www20.brinkster.com/deyanp/dynproxy/DynamicProxyAvalonTest.zip

Class1.cs looks now like this:

using System;

namespace DynamicProxyAvalonTest
{
 class Class1
 {
  [STAThread]
  static void Main(string[] args)
  {
   Test(1000, 1, true);
   Test(1000, 1, false);
   Test(1000, 1, true);
   Test(1000, 1, false);
   Test(1000, 1, true);
   Test(1000, 1, false);
   Test(1000, 1, true);
   Test(1000, 1, false);

   Test(1000, 100, true);
   Test(1000, 100, false);
   Test(1000, 100, true);
   Test(1000, 100, false);
   Test(1000, 100, true);
   Test(1000, 100, false);
   Test(1000, 100, true);
   Test(1000, 100, false);

   Test(1000, 1000, true);
   Test(1000, 1000, false);
   Test(1000, 1000, true);
   Test(1000, 1000, false);
   Test(1000, 1000, true);
   Test(1000, 1000, false);
   Test(1000, 1000, true);
   Test(1000, 1000, false);

   Console.ReadLine();
  }

  public static void Test(int maxi, int maxj, bool useProxy)
  {
   int start = Environment.TickCount;
   int i = 0;
   int j = 0;
   for(i=0;i<maxi;i++)
   {
    //useProxy=true lazy-loads the referenced country
    //a dynamic proxy is stuffed in
    //altogether 2 db calls: 1 for the user
    //and later 1 for the country
    //useProxy=false eager-loads the referenced country
    //the country is directly retrieved from the db upon retrieval of the
user
    //in a separate db call
    //altogether 2 db calls: 1 for the user
    //and immediately another 1 for the country
    User user = UserDA.Select(1830, useProxy);
    for(j=0;j<maxj;j++)
    {
     int d = user.ID;
     string n = user.Name;
     if(user.Country != null)
     {
      int d2 = user.Country.ID;
      string n2 = user.Country.Name;
     }
    }
   }
   int end = Environment.TickCount;
   Console.WriteLine(String.Format("Loop[i={0},j={1}] useProxy={2}
Test:\t\t\t{3}", i, j, useProxy, end - start));

  }
 }
}


The results are the following:

Loop[i=1000,j=1] useProxy=True Test:                    1219
Loop[i=1000,j=1] useProxy=False Test:                   781
Loop[i=1000,j=1] useProxy=True Test:                    890
Loop[i=1000,j=1] useProxy=False Test:                   782
Loop[i=1000,j=1] useProxy=True Test:                    890
Loop[i=1000,j=1] useProxy=False Test:                   813
Loop[i=1000,j=1] useProxy=True Test:                    906
Loop[i=1000,j=1] useProxy=False Test:                   812
Loop[i=1000,j=100] useProxy=True Test:                  1485
Loop[i=1000,j=100] useProxy=False Test:                 734
Loop[i=1000,j=100] useProxy=True Test:                  1406
Loop[i=1000,j=100] useProxy=False Test:                 719
Loop[i=1000,j=100] useProxy=True Test:                  1406
Loop[i=1000,j=100] useProxy=False Test:                 766
Loop[i=1000,j=100] useProxy=True Test:                  1437
Loop[i=1000,j=100] useProxy=False Test:                 766
Loop[i=1000,j=1000] useProxy=True Test:                 5859
Loop[i=1000,j=1000] useProxy=False Test:                 813
Loop[i=1000,j=1000] useProxy=True Test:                 5859
Loop[i=1000,j=1000] useProxy=False Test:                  813
Loop[i=1000,j=1000] useProxy=True Test:                 5843
Loop[i=1000,j=1000] useProxy=False Test:                  922
Loop[i=1000,j=1000] useProxy=True Test:                 6031
Loop[i=1000,j=1000] useProxy=False Test:                  891


It seems that the inner loop causes performance problems - if the value is 1
then there is almost no difference between the proxy and no proxy versions,
but if it is 1000, then the difference is 6x.

Let me know what you think about this, if you find time for that. I will
continue investigating the issue tomorrow.


Best regards,
Deyan

Re: [Aspectsharp-users] IInvocation.Proxy and IInvocation.InvocationTarget

[hammett <ha...@uo...>]

Hello Deyan
Very interesting piece of code. So, you return a place holder with lazy 
load. Is it something that the user can turn on and off?

About the code, I've implemented the writable InvocationTarget and changed 
your code interceptor to:

public class MyInterceptor : IInterceptor
{
 private LoadObjectDelegate _loadObjectDelegate;
 private int _id;
 private bool isLoaded;
 private object newtarget;

 public MyInterceptor(LoadObjectDelegate loadObjectDelegate, int id)
 {
  _loadObjectDelegate = loadObjectDelegate;
  _id = id;
 }

 public object Intercept( IInvocation invocation, params object[] args)
 {
  if(invocation.Method.Name.Equals("get_ID"))
  {
   return _id;
  }

  if (!isLoaded)
  {
   newtarget = _loadObjectDelegate( _id );
   isLoaded = true;
  }
  invocation.InvocationTarget = newtarget;

  return invocation.Proceed(args);
 }
}

The results were

Loop1000DynamicProxyTest: 125
Loop1000 NoProxy Test: 16
Loop1000DynamicProxyTest: 47
Loop1000 NoProxy Test: 0

(using Environment.TickCount instead of DateTime.Now)

From my standpoint this is good. The first one takes more time because the 
proxy code generation. After that, it will use the cached type.
Now, a better test will be to implement a simple but functional Materialize 
method, to load it from the database and check if the lazy load is really 
effective. If the proxy overhead is really making the overall process too 
slow, we can tweak it as you wish   :-)

I'm commiting the changes to SVN right now.

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett


----- Original Message ----- 
From: "Deyan Petrov" <de...@ho...>
To: <asp...@li...>
Sent: Thursday, October 28, 2004 12:45 AM
Subject: Re: [Aspectsharp-users] IInvocation.Proxy and 
IInvocation.InvocationTarget 

Re: [Aspectsharp-users] IInvocation.Proxy and IInvocation.InvocationTarget

[Deyan P. <de...@ho...>]

Hi,

Obviously my reply from yesterday with an attachment was blocked. So I send
another one, this time I have placed my test project on the web:


http://www20.brinkster.com/deyanp/dynproxy/DynamicProxyAvalonTest.zip

10x, hammett, and sorry to bother you with this.

Br,
Deyan

----- Original Message ----- 
From: "hammett" <ha...@uo...>
To: <asp...@li...>
Sent: Wednesday, October 27, 2004 8:15 PM
Subject: Re: [Aspectsharp-users] IInvocation.Proxy and
IInvocation.InvocationTarget


> Hello Deyan,
>
> > I have been playing with the new IInvocation, and I noticed that both
> > properties IInvocation.Proxy and IInvocation.InvocationTarget are the
> > same.
> > What's there meaning, btw?
>
> The target means: when I invoke proceed, which object will receive the
> execution; and the proxy is the proxy itself. When proxying a class, both
> values will be the same. When intercepting interfaces (using
> ProxyGenerator.CreateProxy) then the values will be different.
>
> > What is bothering me is that there is no way to substitute the real
object
> > in the PreProcess method of my Interceptor, which is a part of the
object
> > lazy-loading process...
>
> Well, this is easy to fix. We can make the InvocationTarget writable, but
> then the Proceed in the SameClassInvocation must be changed to something
> like:
>
>   public override object Proceed(params object[] args)
>   {
>     object value = null;
>     if (TargetInvocation == Proxy)
>     {
>       value = call.Call( args );
>     }
>     else
>     {
>       value = Method.Invoke( InvocationTarget, args );
>     }
>    return value;
>   }
>
> Because there is no wasy to use the delegate to invoke the method
somewhere
> else. I could even generate two different delegates: one to invoke the
> base() and one to invoke anotherobject() but in this case I must know the
> Type of the anotherobject during the object generation, something like:
>
> private void callback_1(int x)
> {
>   base.DoSomething(x);
> }
>
> private void otherobjectcallback(int x)
> {
>   // This is generated by
>   // gen.Emit( OpCodes.callvirt, typeof(target).GetMethod("DoSomething",
new
> type[] { typeof(int) } );
>   target.DoSomething(x);
> }
>
>
> > I see that NHibernate also has this problem, as it
> > retrieves the real object from the db and delegates (using runtime
> > reflection) the calls to it. I would like to execute the methods on the
> > real
> > object without runtime reflection, which means that either I can
substitte
> > the real object (perhaps this is the IInvocation.InvocationTarget which
> > has
> > only a getter) - this I think is not possible, or populate the
properties
> > of
> > the proxy from the db at runtime, and then take advantage of the Dynamic
> > Proxy new calling infrastructure.
>
> Can you expose your code somewhere so we can see exactly the problem?
> It will be easier to picture the solution...
>
> --
> Cheers,
> hammett
> http://www.digitalcraftsmen.com.br/~hammett
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Aspectsharp-users mailing list
> Asp...@li...
> https://lists.sourceforge.net/lists/listinfo/aspectsharp-users
>

[Aspectsharp-users] Castle task list

[hammett <ha...@uo...>]

Hello,

This is way off topic, but I've compiled a list of to-dos for Castle 
project - which is the bigger picture from where Dynamic Proxy is just one 
more tool. We plan to provide facilities to NHibernate/Ojb.Net/Ibatis as 
long as our licenses are compatible.

If you can't get enough aggravation in your life and want to join another 
challenging project, you're welcome! :-D
Just hand me the username in sourceforge list and I'll add you as soon as 
our project takeover process is finished.

http://www.digitalcraftsmen.com.br/svn/castle/trunk/castle-todos.txt

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett

Re: [Aspectsharp-users] Possible solution to serialization issues

[<hen...@gm...>]

+1 in put it off for now.

And further changes in the proxy serialization won't affect the users
that follow this strategy ( I think so ).

On Wed, 27 Oct 2004 16:19:31 -0700, hammett <ha...@uo...> wrote:
> But which one? Put it off or implement this beast? :-)
> I'm +1 to put it off for now 'til castle development and prevalence
> integration is the under way..
>=20
> --
> Cheers,
> hammett
> http://www.digitalcraftsmen.com.br/~hammett
>=20
> ----- Original Message -----
> From: "Henry Concei=E7=E3o" <hen...@gm...>
> To: "hammett" <ha...@uo...>
> Sent: Wednesday, October 27, 2004 11:49 AM
> Subject: Re: [Aspectsharp-users] Possible solution to serialization issue=
s
>=20
> I think that it for now is good enough... :-)
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_idU88&alloc_id=12065&opclick
>=20
>=20
> _______________________________________________
> Aspectsharp-users mailing list
> Asp...@li...
> https://lists.sourceforge.net/lists/listinfo/aspectsharp-users
>=20


--=20
Cheers,
Henry Concei=E7=E3o

Re: [Aspectsharp-users] Possible solution to serialization issues

[hammett <ha...@uo...>]

But which one? Put it off or implement this beast? :-)
I'm +1 to put it off for now 'til castle development and prevalence=20
integration is the under way..

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett


----- Original Message -----=20
From: "Henry Concei=E7=E3o" <hen...@gm...>
To: "hammett" <ha...@uo...>
Sent: Wednesday, October 27, 2004 11:49 AM
Subject: Re: [Aspectsharp-users] Possible solution to serialization issue=
s


I think that it for now is good enough... :-)

[Aspectsharp-users] Possible solution to serialization issues

[hammett <ha...@uo...>]

Hiya,
(I'm cc rodrigo wondering if he knows a better solution)

Our problems with serialization regard mostly people that serialize an 
object model with aspects involved and need to retrive them later as they 
were. Seems easy but its a bit tricky:

- The types are transient types in an transient assembly. The CLR is not 
able to serialize them
- The proxy must serialize the state of the base class unaware of how the 
base class has chosen the serialization method (flag or ISerializable 
interface)

My suggestion is very intrusive, but it works:

1. Types that want to be serialized and that you know up front will be 
proxied must use the ISerializable interface.
2. The dynamic proxy generated will implement the GetObjectData saving its 
information and calling the base GetObjectData and setting a custom 
IObjectReference, which is not transient.
3. The dynamic proxy will expose a public constructor to deserialization 
just to delegate to the base class deserialization constructor
4. The custom IObjectReference should recreate the proxy and invoke the 
deserialization constructor

Caveats: to guarantee the correct behavior we need to force classes marked 
as serializable to implement both methods, which translates to: if you want 
to proxy a class marked as serializable, an error will be raised unless you 
implement the constructor and the virtual GetObjectData. This is terrible.

Anyone has a better solution? Or we can put off this for now.

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett 

Re: [Aspectsharp-users] IInvocation.Proxy and IInvocation.InvocationTarget

[hammett <ha...@uo...>]

Hello Deyan,

> I have been playing with the new IInvocation, and I noticed that both
> properties IInvocation.Proxy and IInvocation.InvocationTarget are the 
> same.
> What's there meaning, btw?

The target means: when I invoke proceed, which object will receive the 
execution; and the proxy is the proxy itself. When proxying a class, both 
values will be the same. When intercepting interfaces (using 
ProxyGenerator.CreateProxy) then the values will be different.

> What is bothering me is that there is no way to substitute the real object
> in the PreProcess method of my Interceptor, which is a part of the object
> lazy-loading process...

Well, this is easy to fix. We can make the InvocationTarget writable, but 
then the Proceed in the SameClassInvocation must be changed to something 
like:

  public override object Proceed(params object[] args)
  {
    object value = null;
    if (TargetInvocation == Proxy)
    {
      value = call.Call( args );
    }
    else
    {
      value = Method.Invoke( InvocationTarget, args );
    }
   return value;
  }

Because there is no wasy to use the delegate to invoke the method somewhere 
else. I could even generate two different delegates: one to invoke the 
base() and one to invoke anotherobject() but in this case I must know the 
Type of the anotherobject during the object generation, something like:

private void callback_1(int x)
{
  base.DoSomething(x);
}

private void otherobjectcallback(int x)
{
  // This is generated by
  // gen.Emit( OpCodes.callvirt, typeof(target).GetMethod("DoSomething", new 
type[] { typeof(int) } );
  target.DoSomething(x);
}


> I see that NHibernate also has this problem, as it
> retrieves the real object from the db and delegates (using runtime
> reflection) the calls to it. I would like to execute the methods on the 
> real
> object without runtime reflection, which means that either I can substitte
> the real object (perhaps this is the IInvocation.InvocationTarget which 
> has
> only a getter) - this I think is not possible, or populate the properties 
> of
> the proxy from the db at runtime, and then take advantage of the Dynamic
> Proxy new calling infrastructure.

Can you expose your code somewhere so we can see exactly the problem?
It will be easier to picture the solution...

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett

[Aspectsharp-users] IInvocation.Proxy and IInvocation.InvocationTarget

[Deyan P. <de...@ho...>]

Hi,

I have been playing with the new IInvocation, and I noticed that both
properties IInvocation.Proxy and IInvocation.InvocationTarget are the same.
What's there meaning, btw?

What is bothering me is that there is no way to substitute the real object
in the PreProcess method of my Interceptor, which is a part of the object
lazy-loading process... I see that NHibernate also has this problem, as it
retrieves the real object from the db and delegates (using runtime
reflection) the calls to it. I would like to execute the methods on the real
object without runtime reflection, which means that either I can substitte
the real object (perhaps this is the IInvocation.InvocationTarget which has
only a getter) - this I think is not possible, or populate the properties of
the proxy from the db at runtime, and then take advantage of the Dynamic
Proxy new calling infrastructure.

Hammett, Mike, what do you think about this? Mike, don't you have a problem
with the Method.Invoke on the real object(AvalonLazyInitializer.Invoke, the
case when result==InvokeImplementation), which means that a lazy-loaded
object always uses reflection (during it's whole lifetime) when a
method/property is called on it?

10x and br,
Deyan

----- Original Message ----- 
From: "hammett" <ha...@uo...>
To: <asp...@li...>
Sent: Tuesday, October 26, 2004 7:38 AM
Subject: [Aspectsharp-users] Non-virtual methods again


> Hello!
>
> I was thinking about it again, and now its safe to allow non-virtual
methods
> in the classes being proxied as just one instance will exist. The result
is:
> non-virtual methods wont be intercepted...
>
> What are your thoughts?
>
> --
> Cheers,
> hammett
> http://www.digitalcraftsmen.com.br/~hammett
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Aspectsharp-users mailing list
> Asp...@li...
> https://lists.sourceforge.net/lists/listinfo/aspectsharp-users
>

Re: [Aspectsharp-users] Non-virtual methods again

[hammett <ha...@uo...>]

Ok, guys.
I've changed to ignore non-virtual and sealed methods. Test cases are 
passing.
Its on the svn.

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett


----- Original Message ----- 
From: "Mike Doerfler" <mik...@gm...>

Re: [Aspectsharp-users] IInvocationHandler is dead. Long live IInterceptor and IInvocation

[hammett <ha...@uo...>]

----- Original Message -----=20
From: "Henry Concei=E7=E3o" <hen...@gm...>


> And what about serialize the entire Proxy, it's less worse? ;-)

It would be fine if the CLR didn't complain..

> I can't figure out how avoid reflection to inspect the privates fields
> of all object's hierarchy, since all the proxies are subClass of the
> proxied class.

Yes, still thinking about it... Maybe there is no other way..

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett
=20

Re: [Aspectsharp-users] Non-virtual methods again

[Mike D. <mik...@gm...>]

+1 - to allowing non-virtual methods and not intercepting them

Keep up the good work!

Mike


On Tue, 26 Oct 2004 12:32:10 -0300, Henry Concei=E7=E3o
<hen...@gm...> wrote:
> I like this way more than throw an exception or ignore the method
>=20
>=20
>=20
>=20
> On Mon, 25 Oct 2004 22:38:25 -0700, hammett <ha...@uo...> wrote:
> > Hello!
> >
> > I was thinking about it again, and now its safe to allow non-virtual me=
thods
> > in the classes being proxied as just one instance will exist. The resul=
t is:
> > non-virtual methods wont be intercepted...
> >
> > What are your thoughts?
> >
> > --
> > Cheers,
> > hammett
> > http://www.digitalcraftsmen.com.br/~hammett
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IT Product Guide on ITManagersJourna=
l
> > Use IT products in your business? Tell us what you think of them. Give =
us
> > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out =
more
> > http://productguide.itmanagersjournal.com/guidepromo.tmpl
> > _______________________________________________
> > Aspectsharp-users mailing list
> > Asp...@li...
> > https://lists.sourceforge.net/lists/listinfo/aspectsharp-users
> >
>=20
>=20
> --
> Cheers,
> Henry Concei=E7=E3o
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out mo=
re
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Aspectsharp-users mailing list
> Asp...@li...
> https://lists.sourceforge.net/lists/listinfo/aspectsharp-users
>

Re: [Aspectsharp-users] IInvocationHandler is dead. Long live IInterceptor and IInvocation

[<hen...@gm...>]

And what about serialize the entire Proxy, it's less worse? ;-)

I can't figure out how avoid reflection to inspect the privates fields
of all object's hierarchy, since all the proxies are subClass of the
proxied class.


On Tue, 26 Oct 2004 14:21:31 -0700, hammett <ha...@uo...> wrote:
> > I thougth in use reflection to inspect the fields and retrieve
> > the values, So I'd decided to try this approach and the first results a=
re:
>=20
> Sounds like the worst approach... But I can only spend more time on this
> next weekend.
>=20
>=20
> --
> Cheers,
> hammett
> http://www.digitalcraftsmen.com.br/~hammett
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
>=20
>=20
> _______________________________________________
> Aspectsharp-users mailing list
> Asp...@li...
> https://lists.sourceforge.net/lists/listinfo/aspectsharp-users
>=20


--=20
Cheers,
Henry Concei=E7=E3o

Re: [Aspectsharp-users] IInvocationHandler is dead. Long live IInterceptor and IInvocation

[hammett <ha...@uo...>]

> I thougth in use reflection to inspect the fields and retrieve
> the values, So I'd decided to try this approach and the first results are:

Sounds like the worst approach... But I can only spend more time on this 
next weekend.


--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett

Re: [Aspectsharp-users] Non-virtual methods again

[Deyan P. <de...@ho...>]

Hi,

I also don't have a problem with this scenario. There is, of course, a
fundamental problem - that there is no other nice way to generate proxies
but to create subclasses (which override base classes methods) .. and that
C# doesn't have all class methods virtual by default, but we have to live
with that ;)

Br,
Deyan


----- Original Message ----- 
From: "Henry Conceição" <hen...@gm...>
To: "hammett" <ha...@uo...>
Cc: <asp...@li...>
Sent: Tuesday, October 26, 2004 5:32 PM
Subject: Re: [Aspectsharp-users] Non-virtual methods again


I like this way more than throw an exception or ignore the method


On Mon, 25 Oct 2004 22:38:25 -0700, hammett <ha...@uo...> wrote:
> Hello!
>
> I was thinking about it again, and now its safe to allow non-virtual
methods
> in the classes being proxied as just one instance will exist. The result
is:
> non-virtual methods wont be intercepted...
>
> What are your thoughts?
>
> --
> Cheers,
> hammett
> http://www.digitalcraftsmen.com.br/~hammett
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Aspectsharp-users mailing list
> Asp...@li...
> https://lists.sourceforge.net/lists/listinfo/aspectsharp-users
>


-- 
Cheers,
Henry Conceição


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Aspectsharp-users mailing list
Asp...@li...
https://lists.sourceforge.net/lists/listinfo/aspectsharp-users

Re: [Aspectsharp-users] IInvocationHandler is dead. Long live IInterceptor and IInvocation

[<hen...@gm...>]

> == Serialization ==

> - The GetObjectData implementation should (somehow) be able to persist the
> fields of the super class (need to stop to think about it carefully)

I thougth in use reflection to inspect the fields and retrieve
the values, So I'd decided to try this approach and the first results are:

- Type.GetFields doesn't work as expected, ex:

<snip>
ExtendedSerializableClass type = new ExtendedSerializableClass();

BindingFlags bindingFlags = BindingFlags.Static |
BindingFlags.NonPublic | BindingFlags.FlattenHierarchy;

FieldInfo[] fields = type.GetType().GetFields( bindingFlags );

Assert.AreEqual(1, fields.Length);

<snip>
The test below doesn't pass ( fields.Length returns 0 ).

The ExtendedSerializableClass extends the MySerializableClass which I
added a static string Iah. Anyway, I'll look this with more attention;

- Security Issues: " If the requested type is non-public and the caller
does not have ReflectionPermission to reflect non-public objects
outside the current assembly, this method returns a null reference
(Nothing in Visual Basic). " - Microsoft .NET Framework Documentation;

Not so exciting...

Re: [Aspectsharp-users] Non-virtual methods again

[<hen...@gm...>]

I like this way more than throw an exception or ignore the method


On Mon, 25 Oct 2004 22:38:25 -0700, hammett <ha...@uo...> wrote:
> Hello!
>=20
> I was thinking about it again, and now its safe to allow non-virtual meth=
ods
> in the classes being proxied as just one instance will exist. The result =
is:
> non-virtual methods wont be intercepted...
>=20
> What are your thoughts?
>=20
> --
> Cheers,
> hammett
> http://www.digitalcraftsmen.com.br/~hammett
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out mo=
re
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Aspectsharp-users mailing list
> Asp...@li...
> https://lists.sourceforge.net/lists/listinfo/aspectsharp-users
>=20


--=20
Cheers,
Henry Concei=E7=E3o

[Aspectsharp-users] Non-virtual methods again

[hammett <ha...@uo...>]

Hello!

I was thinking about it again, and now its safe to allow non-virtual methods 
in the classes being proxied as just one instance will exist. The result is: 
non-virtual methods wont be intercepted...

What are your thoughts?

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett

Re: [Aspectsharp-users] IInvocationHandler is dead. Long live IInterceptor and IInvocation

[hammett <ha...@uo...>]

Hello Deyan!

I've opened our svn to anonymous access. Please, check the code here:
http://www.digitalcraftsmen.com.br/svn/castle/trunk/Tools/DynamicProxy/
(The serialization test cases are not passing)

Anyway, as soon as sf.net allow us to use the http://castle.sf.net I'll make
the first release available.

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett

----- Original Message ----- 
From: "Deyan Petrov" <de...@ho...>
To: <asp...@li...>
Sent: Monday, October 25, 2004 2:16 AM
Subject: Re: [Aspectsharp-users] IInvocationHandler is dead. Long live 
IInterceptor and IInvocation


> Hi hammett,
>
> Sounds great! Where can I get the updated sources from so that I can start
> playing with them?
>
> 10x,
> Deyan Petrov

Re: [Aspectsharp-users] IInvocationHandler is dead. Long live IInterceptor and IInvocation

[Deyan P. <de...@ho...>]

Hi hammett,

Sounds great! Where can I get the updated sources from so that I can start
playing with them?

10x,
Deyan Petrov

----- Original Message ----- 
From: "hammett" <ha...@uo...>
To: <asp...@li...>
Sent: Monday, October 25, 2004 12:12 PM
Subject: [Aspectsharp-users] IInvocationHandler is dead. Long live
IInterceptor and IInvocation


> Hello dudes,
>
> After a few hours (ok, several) and now almost able to write a book about
IL
> programming, I finally finished the DynamicProxy refactory. What changed?
>
>
> == Interface proxy ==
>
> Dynamic Proxy still able to proxy interfaces, but the public interface
> changed from
>
>   proxygenerator.CreateProxy( Type, IInvocationHandler )
>
> to
>
>   proxygenerator.CreateProxy( Type, IInterceptor, object target )
>
> The target is null or what implements the interface being proxy. The
> IInterceptor interface follows
>
>  public interface IInterceptor
>  {
>   object Intercept( IInvocation invocation, params object[] args );
>  }
>
> (I know, from a OOP PoV the IInvocation should store the arguments too,
but
> this usage allows us to cache the invocation instance)
>
> A StandardInterceptor is provided to make things even simpler.
>
>
>
> == Concrete classes proxy ==
>
> The public interface changed from
>
>   proxygenerator.CreateClassProxy( Type, IInvocationHandler )
>
> to
>
>   proxygenerator.CreateClassProxy( Type, IInterceptor )
>
>
>
> == Under the hood ==
>
> While little changed in the public interface, a lot changed in the
generated
> code. Inspired by how boo deals with closures (http://boo.codehaus.org)
I've
> created an ICallable interface which is implemented by nested delegates in
> the proxy class. The eq. C# code would be something like
>
> class MyClassProxy : MyClass
> {
>   public sealed class _Delegate_Do_1 : MulticastDelegate, ICallable
>   {
>     public _Delegate_Do_1(object target, intptr methodoffset)
>     {}
>
>     public void Invoke(int x, int y)
>     {}
>
>     public virtual object Call( params object[] args )
>     {
>       this( (int) args[0], (int) args[1] ); // Invokes the delegate
>     }
>   }
>
>   public MyClassProxy( IInterceptor interceptor ) : base()
>   {
>     this.interceptor = interceptor;
>   }
>
>   public override void Do(int x, int y)
>   {
>     MethodBase m = MethodBase.GetMethodFromHandler( ldtoken m );
>     IInvocation invocation = _Method2Invocation( new
> _Delegate_Do_1(callback_Do), this, m  );
>     invocation.Intercept( invocation );
>   }
>
>   private void callback_Do( int x, int y )
>   {
>     base.Do(x, y);
>   }
> }
>
> This allows an elegant invocation.Proceed() to invoke the base method or
the
> interface implementation.
> The performance should be very good, better than it was as there is _no_
> invocation through reflection anymore. :-)
>
> == Serialization ==
>
> The GetObjectData is partially implemented, and the ProxyObjectReference
is
> capable of recreating the proxy instance. What is left to be solved (I
need
> to sleep right now zzz)
>
> - The GetObjectData implementation should (somehow) be able to persist the
> fields of the super class (need to stop to think about it carefully)
> - The GetObjectData should save a type array of interfaces implemented by
> the proxy
> - The GetObjectData should invoke a virtual method passing the ILGenerator
> along, allowing augmenting it easily
>
>
> All of this impact Aspect#, that need to be refactored as well. I plan to
do
> it this very week. Suggestions are welcome!
>
> Night!
>
> --
> Cheers,
> hammett
> http://www.digitalcraftsmen.com.br/~hammett
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Aspectsharp-users mailing list
> Asp...@li...
> https://lists.sourceforge.net/lists/listinfo/aspectsharp-users
>

[Aspectsharp-users] IInvocationHandler is dead. Long live IInterceptor and IInvocation

[hammett <ha...@uo...>]

Hello dudes,

After a few hours (ok, several) and now almost able to write a book about IL 
programming, I finally finished the DynamicProxy refactory. What changed?


== Interface proxy ==

Dynamic Proxy still able to proxy interfaces, but the public interface 
changed from

  proxygenerator.CreateProxy( Type, IInvocationHandler )

to

  proxygenerator.CreateProxy( Type, IInterceptor, object target )

The target is null or what implements the interface being proxy. The 
IInterceptor interface follows

 public interface IInterceptor
 {
  object Intercept( IInvocation invocation, params object[] args );
 }

(I know, from a OOP PoV the IInvocation should store the arguments too, but 
this usage allows us to cache the invocation instance)

A StandardInterceptor is provided to make things even simpler.



== Concrete classes proxy ==

The public interface changed from

  proxygenerator.CreateClassProxy( Type, IInvocationHandler )

to

  proxygenerator.CreateClassProxy( Type, IInterceptor )



== Under the hood ==

While little changed in the public interface, a lot changed in the generated 
code. Inspired by how boo deals with closures (http://boo.codehaus.org) I've 
created an ICallable interface which is implemented by nested delegates in 
the proxy class. The eq. C# code would be something like

class MyClassProxy : MyClass
{
  public sealed class _Delegate_Do_1 : MulticastDelegate, ICallable
  {
    public _Delegate_Do_1(object target, intptr methodoffset)
    {}

    public void Invoke(int x, int y)
    {}

    public virtual object Call( params object[] args )
    {
      this( (int) args[0], (int) args[1] ); // Invokes the delegate
    }
  }

  public MyClassProxy( IInterceptor interceptor ) : base()
  {
    this.interceptor = interceptor;
  }

  public override void Do(int x, int y)
  {
    MethodBase m = MethodBase.GetMethodFromHandler( ldtoken m );
    IInvocation invocation = _Method2Invocation( new 
_Delegate_Do_1(callback_Do), this, m  );
    invocation.Intercept( invocation );
  }

  private void callback_Do( int x, int y )
  {
    base.Do(x, y);
  }
}

This allows an elegant invocation.Proceed() to invoke the base method or the 
interface implementation.
The performance should be very good, better than it was as there is _no_ 
invocation through reflection anymore. :-)

== Serialization ==

The GetObjectData is partially implemented, and the ProxyObjectReference is 
capable of recreating the proxy instance. What is left to be solved (I need 
to sleep right now zzz)

- The GetObjectData implementation should (somehow) be able to persist the 
fields of the super class (need to stop to think about it carefully)
- The GetObjectData should save a type array of interfaces implemented by 
the proxy
- The GetObjectData should invoke a virtual method passing the ILGenerator 
along, allowing augmenting it easily


All of this impact Aspect#, that need to be refactored as well. I plan to do 
it this very week. Suggestions are welcome!

Night!

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett

[Aspectsharp-users] Proposals performance tests

[hammett <ha...@uo...>]

Testing with delegates (using the DynamicInvoke method)
= 10000 * 2 executions Took 125 ms

Testing the Deyan's suggestion
= 10000 * 2 executions Took 47 ms

Before any further step I blame the DynamicInvoke :-).
A better strategy will be

1. DynamicProxy generate each delegate (and the proper invoke) and make this 
class implements a Callable interface.
2. The Callable's call method invokes the delegate itself (without 
DynamicInvoke)

AFAIK this can't be done with C# directly, so it relies on my _feeling_ that 
it'll have a much better performance.

I plan to work more on this tomorrow, have to work on a few websites first 
:-\

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett

Re: [Aspectsharp-users] Proposal: Big Change

[hammett <ha...@uo...>]

Hello Deyan (where's you from btw?)

> Why don't you simply generate something like the stuff below? I think that
> if you don't use runtime reflection the execution will be measurable with
> the unproxied execution, otherwise it's much slower ...:

This is something to be considered.

<snip>

Your proposal is neat, while mine is much more like a kind of 
'continuations' ability. I really don't know which one is better, but I like 
the idea of enveloping the method invocation (the invocation interface)

I'll run some performance tests and will put the results here in a few 
minutes.


Thanks for your support! :-)

--
Cheers,
hammett
http://www.digitalcraftsmen.com.br/~hammett