From hr2j at cs.virginia.edu Mon Jan 12 16:02:16 2004 From: hr2j at cs.virginia.edu (Hridesh Rajan) Date: Thu Mar 23 12:03:17 2006 Subject: [Eos-discuss] test Message-ID: <12cc01c3d94f$5c3e33d0$6400a8c0@prabhat> From andrewilsonfurtado at yahoo.com.br Fri Jan 23 00:31:18 2004 From: andrewilsonfurtado at yahoo.com.br (Andre W B Furtado) Date: Thu Mar 23 12:03:18 2006 Subject: [Eos-discuss] next eos version Message-ID: <004e01c3e172$24908c00$0701a8c0@aw> Hi folks. This message is just to remind EOS-developers to plase send a mail to the list when the next EOS version is ready... (wishes from a humble programmer waiting for "static aspectizing" and "around advices" in order to put applications into production... :) By the way, could you please tell me what is currently supported by thisJoinPoint, besides getArgs, getReturnValue, getTarget and getThis? I'd be really glad to see the possibility to extract some info about the method being called, such as its name. Finishing with a tip: if you are writing a logging aspect and would like to get the return TYPE, rather than the return VALUE from a method, you can always use thisJoinPoint.getReturnValue().GetType() Cheers, -- Andre From hr2j at cs.virginia.edu Fri Jan 23 00:48:10 2004 From: hr2j at cs.virginia.edu (Hridesh Rajan) Date: Thu Mar 23 12:03:18 2006 Subject: [Eos-discuss] next eos version In-Reply-To: <004e01c3e172$24908c00$0701a8c0@aw> Message-ID: <003e01c3e174$7bbac700$39898f80@cs.virginia.edu> Andre and All, First great news: Eos next version is looking good so far, so we can hope it to be out by the last week of the feb deadline. The version will surely address your concerns, plus it will bring a lot more behind the scene. Currently thisJoinPoint only supports the methods that you enumerated. Next version will support thisJoinPointStaticPart which will give you the static information that you require. And lastly thanks for the tip. I propose that we allow users to contribute their sample source code on a web-page with proper acknowledgements. Thank you once again, Rajan -----Original Message----- From: eos-discuss-admin@cs.virginia.edu [mailto:eos-discuss-admin@cs.virginia.edu] On Behalf Of Andre W B Furtado Sent: Friday, January 23, 2004 12:31 AM To: eos-discuss Subject: [Eos-discuss] next eos version Hi folks. This message is just to remind EOS-developers to plase send a mail to the list when the next EOS version is ready... (wishes from a humble programmer waiting for "static aspectizing" and "around advices" in order to put applications into production... :) By the way, could you please tell me what is currently supported by thisJoinPoint, besides getArgs, getReturnValue, getTarget and getThis? I'd be really glad to see the possibility to extract some info about the method being called, such as its name. Finishing with a tip: if you are writing a logging aspect and would like to get the return TYPE, rather than the return VALUE from a method, you can always use thisJoinPoint.getReturnValue().GetType() Cheers, -- Andre _______________________________________________ Eos-discuss mailing list Eos-discuss@cs.virginia.edu http://www.cs.virginia.edu/mailman/listinfo/eos-discuss From andrewilsonfurtado at yahoo.com.br Sat Jan 24 18:07:10 2004 From: andrewilsonfurtado at yahoo.com.br (Andre W B Furtado) Date: Thu Mar 23 12:03:18 2006 Subject: [Eos-discuss] declare parents in eos-0.2? Message-ID: <000901c3e2ce$cd544c20$0701a8c0@aw> Will the second version of Eos have something like AspectJ "declare parents"? Case no, is this intended to be implemented some day? Cheers, -- Andre From andrewilsonfurtado at yahoo.com.br Sun Jan 25 17:48:32 2004 From: andrewilsonfurtado at yahoo.com.br (Andre W B Furtado) Date: Thu Mar 23 12:03:18 2006 Subject: [Eos-discuss] another request for features Message-ID: <000001c3e39e$c5e6c8c0$0701a8c0@aw> I think it would be nice if eos also could introduce attributes into methods and classes. I'm trying to develop a Distribution Aspect (which uses .NET Remoting) and it is necessary to add the Serializable attribute to some of my classes: [Serializable()] public class Account { ... } Is this intended to be implemented some day? Any ideas about how the syntax will look like? Cheers, -- Andre From hr2j at cs.virginia.edu Sun Jan 25 20:17:54 2004 From: hr2j at cs.virginia.edu (Hridesh Rajan) Date: Thu Mar 23 12:03:18 2006 Subject: [Eos-discuss] declare parents in eos-0.2? References: <000901c3e2ce$cd544c20$0701a8c0@aw> Message-ID: <058d01c3e3ab$34859bb0$6400a8c0@prabhat> Thanks Andre, All declare constructs are planned for Eos 0.3 to be out by May 2004 (hopefully). Rajan ----- Original Message ----- From: "Andre W B Furtado" To: "eos-discuss" Sent: Saturday, January 24, 2004 6:07 PM Subject: [Eos-discuss] declare parents in eos-0.2? > Will the second version of Eos have something like AspectJ "declare > parents"? Case no, is this intended to be implemented some day? > > Cheers, > -- Andre > > _______________________________________________ > Eos-discuss mailing list > Eos-discuss@cs.virginia.edu > http://www.cs.virginia.edu/mailman/listinfo/eos-discuss From hr2j at cs.virginia.edu Sun Jan 25 20:21:00 2004 From: hr2j at cs.virginia.edu (Hridesh Rajan) Date: Thu Mar 23 12:03:18 2006 Subject: [Eos-discuss] another request for features References: <000001c3e39e$c5e6c8c0$0701a8c0@aw> Message-ID: <058e01c3e3ab$36360ad0$6400a8c0@prabhat> This will be nice feature to have, but the Eos team will serve its goal better by pushing it to next release i.e 0.3 . Thank you once again for sending out these little examples. They will definitely help us evaluate the feature tradeoff in a better way. -- Rajan ----- Original Message ----- From: "Andre W B Furtado" To: "eos-discuss" Sent: Sunday, January 25, 2004 5:48 PM Subject: [Eos-discuss] another request for features > I think it would be nice if eos also could introduce attributes into methods > and classes. I'm trying to develop a Distribution Aspect (which uses .NET > Remoting) and it is necessary to add the Serializable attribute to some of > my classes: > > [Serializable()] > public class Account { > ... > } > > Is this intended to be implemented some day? Any ideas about how the syntax > will look like? > > Cheers, > -- Andre > > _______________________________________________ > Eos-discuss mailing list > Eos-discuss@cs.virginia.edu > http://www.cs.virginia.edu/mailman/listinfo/eos-discuss From andrewilsonfurtado at yahoo.com.br Mon Jan 26 02:36:54 2004 From: andrewilsonfurtado at yahoo.com.br (Andre W B Furtado) Date: Thu Mar 23 12:03:18 2006 Subject: [Eos-discuss] eos and .NET Framework version Message-ID: <001701c3e3df$2d1be1c0$0701a8c0@aw> It seems Eos-0.01 uses an earlier version of CSC (C# compiler). Will Eos-0.02 support a more recent version? I'm writing a persistence aspect and it would be nice to have some methods/properties supported, such as the HasRows property of OleDbDataReader class (this property was introduced in .NET Framewok v1.1). Cheers, -- Andre From hr2j at cs.virginia.edu Mon Jan 26 05:03:12 2004 From: hr2j at cs.virginia.edu (Hridesh Rajan) Date: Thu Mar 23 12:03:18 2006 Subject: [Eos-discuss] eos and .NET Framework version References: <001701c3e3df$2d1be1c0$0701a8c0@aw> Message-ID: <05d101c3e3f3$a748a5a0$6400a8c0@prabhat> Andre, First clarification, Eos uses the latest version of the CSC available on the system on which it is running. Again I am not sure, how does using an earlier version of CSC affects presence of a specific property in a class which is part of the System library. Can you tell me exactly what error are you encountering? If your code is not proprietary and you are willing to share with Eos developers, we would like to see the scenario in which you are encountering this problem. My best guess is that you are missing a reference to System.Data.dll. A current limitation of the version of Eos you are using is that, it doesn't loads all the .NET framework dlls to keep the compilation time low, so you will have to manually instruct it to load System.Data.dll. Including a reference argument /r: [Path to your .NET Framework ]/System.Data.dll to the command line argument should solve this problem. Please keep us updated on this issue. Thanks, Rajan ----- Original Message ----- From: "Andre W B Furtado" To: "eos-discuss" Sent: Monday, January 26, 2004 2:36 AM Subject: [Eos-discuss] eos and .NET Framework version > It seems Eos-0.01 uses an earlier version of CSC (C# compiler). Will > Eos-0.02 support a more recent version? I'm writing a persistence aspect and > it would be nice to have some methods/properties supported, such as the > HasRows property of OleDbDataReader class (this property was introduced in > .NET Framewok v1.1). > > Cheers, > -- Andre > > _______________________________________________ > Eos-discuss mailing list > Eos-discuss@cs.virginia.edu > http://www.cs.virginia.edu/mailman/listinfo/eos-discuss From andrewilsonfurtado at yahoo.com.br Mon Jan 26 11:55:50 2004 From: andrewilsonfurtado at yahoo.com.br (Andre W B Furtado) Date: Thu Mar 23 12:03:18 2006 Subject: [Eos-discuss] eos and .NET Framework version References: <001701c3e3df$2d1be1c0$0701a8c0@aw> <05d101c3e3f3$a748a5a0$6400a8c0@prabhat> Message-ID: <001101c3e42d$42698a20$0701a8c0@aw> Thanks, you're right! Adding a reference to System.Datal.dll assembly indeed has solved my problem. (Since any VS.NET project automatically references this assembly, I was not caring about it when my application was moved to the eos environment. Coincidently, due to the fact thar OleDbReader.HasRows was introduced only in .NET Framework 1.1, I wrongly concluded that Eos was using an earlier version). I just can't figure out the following issue (not an AOP or Eos question): Why do I have to use the absolute path to reference System.Data.dll when a relative path to System.Runtime.Remoting.dll is enough...? In order words, the following compilation instruction doesn't work: /r:System.Data.dll And the following instructions do work: /r:[PATH to .NET Framework]\System.Data.dll /r:System.Runtime.Remoting.dll Cheers, -- Andre ----- Original Message ----- From: "Hridesh Rajan" To: "Andre W B Furtado" ; "eos-discuss" Sent: Monday, January 26, 2004 7:03 AM Subject: Re: [Eos-discuss] eos and .NET Framework version > Andre, > > First clarification, Eos uses the latest version of the CSC available on the > system on which it is running. Again I am not sure, how does using an > earlier version of CSC affects presence of a specific property in a class > which is part of the System library. Can you tell me exactly what error are > you encountering? If your code is not proprietary and you are willing to > share with Eos developers, we would like to see the scenario in which you > are encountering this problem. > > My best guess is that you are missing a reference to System.Data.dll. A > current limitation of the version of Eos you are using is that, it doesn't > loads all the .NET framework dlls to keep the compilation time low, so you > will have to manually instruct it to load System.Data.dll. Including a > reference argument /r: [Path to your .NET Framework ]/System.Data.dll to the > command line argument should solve this problem. Please keep us updated on > this issue. > > Thanks, > Rajan > > ----- Original Message ----- > From: "Andre W B Furtado" > To: "eos-discuss" > Sent: Monday, January 26, 2004 2:36 AM > Subject: [Eos-discuss] eos and .NET Framework version > > > > It seems Eos-0.01 uses an earlier version of CSC (C# compiler). Will > > Eos-0.02 support a more recent version? I'm writing a persistence aspect > and > > it would be nice to have some methods/properties supported, such as the > > HasRows property of OleDbDataReader class (this property was introduced in > > .NET Framewok v1.1). > > > > Cheers, > > -- Andre > > > > _______________________________________________ > > Eos-discuss mailing list > > Eos-discuss@cs.virginia.edu > > http://www.cs.virginia.edu/mailman/listinfo/eos-discuss