Hello, Please some body who used AJHotDraw can help me these errors in two Classes mentioned below.
//aspects.org.jhotdraw.contrib public class SVGStorageFormat extends StandardStorageFormat //SVGStorageFormat.java //aspects.org.jhotdraw.util public class JDOStorageFormat extends StandardStorageFormat // StandardStorageFormat.java Type can not resolved, Thanking You, Regards S Kotrappa On Thu, Dec 15, 2011 at 3:34 AM, <[email protected]> wrote: > Send aspectj-users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://dev.eclipse.org/mailman/listinfo/aspectj-users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of aspectj-users digest..." > > > Today's Topics: > > 1. AspectJ vs PostSharp? (Mark) > 2. Why annotations are not exposed through JoinPoint.StaticPart? > (Mark) > 3. Re: AspectJ vs PostSharp? (Andy Clement) > 4. Re: Why annotations are not exposed through > JoinPoint.StaticPart? (Andy Clement) > 5. Re: AspectJ vs PostSharp? (Mark) > 6. Re: Why annotations are not exposed through > JoinPoint.StaticPart? (Mark) > 7. Re: AspectJ vs PostSharp? (Andy Clement) > 8. Re: Why annotations are not exposed through > JoinPoint.StaticPart? (Andy Clement) > 9. Re: Why annotations are not exposed through > JoinPoint.StaticPart? (Mark) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 14 Dec 2011 11:17:41 -0800 (PST) > From: Mark <[email protected]> > To: [email protected] > Subject: [aspectj-users] AspectJ vs PostSharp? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > While learning AspectJ I am constantly comparing it against PostSharp - the > aspect framework I used in .NET. Let me give a very brief and somewhat > simplified overview of how PostSharp works (just in case). This way it > would > be easier for me to ask the question. > > 1. .NET code is compiled as usual and produces dll or exe. > 2. A dedicated PostSharp msbuild task kicks in, which reads the dll or exe > produced in (1), parses the MSIL byte code to create the byte code object > model. > 3. Registered user aspects are invoked. PostSharp.Core exposes the MSIL > byte > code object model through a dedicated API, which lets the aspect to > manipulate the model as it pleases (including, but not limited to, creating > new methods and filling in the method instructions). Implementing > crosscutting concerns is done by registering advices with the interesting > join points (similar to those of AspectJ). > 4. Next, the PostSharp.Core engine travels the object model to create the > corresponding .il file. During the traversal it invokes the advices > registered by the aspects in (3). > 5. Finally, MSIL assembler is called to compile the .il file from (4) into > the respective dll or exe. > > This is roughly how the low level PostSharp.Core engine works. It is low > level, because the advice is responsible to inject the MSIL byte code, > meaning the advice author must be comfortable with the MSIL byte code > language. > > (As a side note, PostSharp comes with a higher level API, called > PostSharp.Laos, but in order to have efficient logging, I had to work at > the > PostSharp.Core level) > > Anyway, I am nearing the punchline of my question. The aspect code (written > in C# in my case) is invoked during the compilation of the subject project > and has a complete access to all the metadata of that project. Everything > available to the compiler is made available to the aspect code through the > PostSharp.Core API. > > It so seems to me, that AspectJ compares to PostSharp.Core as the C++ > compares to the assembly language. Coding in AspectJ creates a code to be > run during the compilation, but that code is specified declaratively using > special high level syntax. > > I dare to guess that under the hood, AspectJ contains a logic similar to > that of PostSharp.Core. There should be an object model describing the JVM > byte code, should it? Assuming I am right, is it possible to take advantage > of that model to extend the capabilities exposed through the current high > level declarative AspectJ language? Like having a door into the low level > AspectJ API, much like PostSharp.Core does. > > -- > View this message in context: > http://aspectj.2085585.n4.nabble.com/AspectJ-vs-PostSharp-tp4196604p4196604.html > Sent from the AspectJ - users mailing list archive at Nabble.com. > > > ------------------------------ > > Message: 2 > Date: Wed, 14 Dec 2011 11:27:38 -0800 (PST) > From: Mark <[email protected]> > To: [email protected] > Subject: [aspectj-users] Why annotations are not exposed through > JoinPoint.StaticPart? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > If I grok Java annotations correctly and they are similar to .NET > attributes, > then any state captured by annotations is part of the metadata and thus it > should be available during the compilation. > > If so, then it should be available in JoinPoint.StaticPart, but it is > neither there nor is it in JoinPoint. Why? Does it mean that accessing > annotations through the reflection is so cheap that it is OK to do so in > aspect advices? > > Thanks. > > -- > View this message in context: > http://aspectj.2085585.n4.nabble.com/Why-annotations-are-not-exposed-through-JoinPoint-StaticPart-tp4196637p4196637.html > Sent from the AspectJ - users mailing list archive at Nabble.com. > > > ------------------------------ > > Message: 3 > Date: Wed, 14 Dec 2011 12:54:31 -0800 > From: Andy Clement <[email protected]> > To: [email protected] > Subject: Re: [aspectj-users] AspectJ vs PostSharp? > Message-ID: > <CAAu=nonw3unzmcpd2hdsn19kvwzk94l1sf-8yy3ggwtezlv...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > > I dare to guess that under the hood, AspectJ contains a logic similar > to> that of PostSharp.Core. There should be an object model describing the > JVM> byte code, should it? Assuming I am right, is it possible to take > advantage> of that model to extend the capabilities exposed through the > current high> level declarative AspectJ language? Like having a door into > the low level> AspectJ API, much like PostSharp.Core does. > Yep internally AspectJ is monkeying with the bytecode. Using a > bytecode library to work it at about the level you'd see in assembly > language (so loads, stores, adds, etc). The ability to participate in > this process and modify the bytecode directly is not currently exposed > to the end user. You can write advice (today) that would generate > code (via a bytecode library) on the fly that could be called from > that advice. > > There is no plugin mechanism that lets you go further though, by, for > example, supplying a plugin to the weaver process that could perform > arbitrary bytecode changes before/after AspectJ does its thing. What > would you want to do? > > We also have to keep in mind that AspectJ was intended as an AOP > language and take care to add things that make sense along those lines > rather than becoming a kitchen sink: "'if we can feasibly do that, we > will do that". > > cheers, > Andy > > On 14 December 2011 11:17, Mark <[email protected]> wrote: > > While learning AspectJ I am constantly comparing it against PostSharp - > the > > aspect framework I used in .NET. Let me give a very brief and somewhat > > simplified overview of how PostSharp works (just in case). This way it > would > > be easier for me to ask the question. > > > > 1. .NET code is compiled as usual and produces dll or exe. > > 2. A dedicated PostSharp msbuild task kicks in, which reads the dll or > exe > > produced in (1), parses the MSIL byte code to create the byte code object > > model. > > 3. Registered user aspects are invoked. PostSharp.Core exposes the MSIL > byte > > code object model through a dedicated API, which lets the aspect to > > manipulate the model as it pleases (including, but not limited to, > creating > > new methods and filling in the method instructions). Implementing > > crosscutting concerns is done by registering advices with the interesting > > join points (similar to those of AspectJ). > > 4. Next, the PostSharp.Core engine travels the object model to create the > > corresponding .il file. During the traversal it invokes the advices > > registered by the aspects in (3). > > 5. Finally, MSIL assembler is called to compile the .il file from (4) > into > > the respective dll or exe. > > > > This is roughly how the low level PostSharp.Core engine works. It is low > > level, because the advice is responsible to inject the MSIL byte code, > > meaning the advice author must be comfortable with the MSIL byte code > > language. > > > > (As a side note, PostSharp comes with a higher level API, called > > PostSharp.Laos, but in order to have efficient logging, I had to work at > the > > PostSharp.Core level) > > > > Anyway, I am nearing the punchline of my question. The aspect code > (written > > in C# in my case) is invoked during the compilation of the subject > project > > and has a complete access to all the metadata of that project. Everything > > available to the compiler is made available to the aspect code through > the > > PostSharp.Core API. > > > > It so seems to me, that AspectJ compares to PostSharp.Core as the C++ > > compares to the assembly language. Coding in AspectJ creates a code to be > > run during the compilation, but that code is specified declaratively > using > > special high level syntax. > > > > I dare to guess that under the hood, AspectJ contains a logic similar to > > that of PostSharp.Core. There should be an object model describing the > JVM > > byte code, should it? Assuming I am right, is it possible to take > advantage > > of that model to extend the capabilities exposed through the current high > > level declarative AspectJ language? Like having a door into the low level > > AspectJ API, much like PostSharp.Core does. > > > > -- > > View this message in context: > http://aspectj.2085585.n4.nabble.com/AspectJ-vs-PostSharp-tp4196604p4196604.html > > Sent from the AspectJ - users mailing list archive at Nabble.com. > > _______________________________________________ > > aspectj-users mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > ------------------------------ > > Message: 4 > Date: Wed, 14 Dec 2011 13:21:21 -0800 > From: Andy Clement <[email protected]> > To: [email protected] > Subject: Re: [aspectj-users] Why annotations are not exposed through > JoinPoint.StaticPart? > Message-ID: > <CAAu=NOkuX0A_6ky3B7bBoFR6=guapc_a4i43khvndepge8c...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > On 14 December 2011 11:27, Mark <[email protected]> wrote: > > If so, then it should be available in JoinPoint.StaticPart, but it is > > neither there nor is it in JoinPoint. Why? > > It isn't directly on either of those, but they are accessible if you > of course. I presume you are doing something like this: for a Field > joinpoint: > > ((FieldSignature)thisJoinPoint.getSignature()).getField().getAnnotations() > > similar thing for methods. It could be exposed directly on JoinPoint > I suppose but it'd just be a cache of the call I showed above - there > isn't any magic in how AspectJ could do it in a more optimal way. > Annotations can't be 'new'd up directly, they tend to have to be > fetched from somewhere. > > > Does it mean that accessing > > annotations through the reflection is so cheap that it is OK to do so in > > aspect advices? > > No, reflection isn't cheap. So you should cache the results if you > are going to keep asking the question. I could cache them in the > joinpoint object, please raise an enhancement request if you want this > but without a few votes it won't be top of the list I'm afraid. > > cheers > Andy > > > ------------------------------ > > Message: 5 > Date: Wed, 14 Dec 2011 13:21:57 -0800 (PST) > From: Mark <[email protected]> > To: [email protected] > Subject: Re: [aspectj-users] AspectJ vs PostSharp? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > Oh, I would want AspectJ to be a kitchen sink. I like it as it is. > > My previous post had too many words, most of them irrelevant to what I am > really looking for in this backdoor. > > There are advices and there are pointcuts. Pointcuts are declared using a > certain syntax. In an ideal world, nothing else is needed. But in reality, > there are things that one cannot express using the current pointcut syntax. > > For instance, I would like to declare a pointcut that matches any method > with only the primitive parameters. The current syntax does not allow me to > do so, does it? I can write something like this: > > pointcut aaa() : execution(* *.*((int || double || char), (int || double || > char), (int || double || char), ..)); > > But I need to list all the primitive types and create several versions of > this pointcut for methods with 0, 1, 2, 3, etc arguments until some > reasonable number. > > In an ideal world AspectJ would have a syntax to describe this pointcut, > but > there is none currently. My backdoor allows to workaround this limitation, > by having something like this: > > pointcut aaa() : MyExecutionPointCut(); > > ExecutionPointCut MyExecutionPointCut() { > // Here comes the Java code constructing the ExecutionPointCut object > describing exactly what I am looking for. This code has access to > everything > that is known at the compile time. > } > > Does it make more sense now? > > -- > View this message in context: > http://aspectj.2085585.n4.nabble.com/AspectJ-vs-PostSharp-tp4196604p4197102.html > Sent from the AspectJ - users mailing list archive at Nabble.com. > > > ------------------------------ > > Message: 6 > Date: Wed, 14 Dec 2011 13:41:47 -0800 (PST) > From: Mark <[email protected]> > To: [email protected] > Subject: Re: [aspectj-users] Why annotations are not exposed through > JoinPoint.StaticPart? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > So, basically it is only available through the reflection on the respective > type/method/field? But, since they are indeed available during the > compilation, you could have cached them in thisJoinPointStaticPart? > > I would really like this feature, so here you go - > https://bugs.eclipse.org/bugs/show_bug.cgi?id=366757 > > Thanks. > > -- > View this message in context: > http://aspectj.2085585.n4.nabble.com/Why-annotations-are-not-exposed-through-JoinPoint-StaticPart-tp4196637p4197179.html > Sent from the AspectJ - users mailing list archive at Nabble.com. > > > ------------------------------ > > Message: 7 > Date: Wed, 14 Dec 2011 13:46:19 -0800 > From: Andy Clement <[email protected]> > To: [email protected] > Subject: Re: [aspectj-users] AspectJ vs PostSharp? > Message-ID: > <CAAu=NO=2ihvkm9do8hspdrv5dysdwhmicbqufcrhvm34gws...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On 14 December 2011 13:21, Mark <[email protected]> wrote: > > Oh, I would want AspectJ to be a kitchen sink. I like it as it is. > > > > My previous post had too many words, most of them irrelevant to what I am > > really looking for in this backdoor. > > > > There are advices and there are pointcuts. Pointcuts are declared using a > > certain syntax. In an ideal world, nothing else is needed. But in > reality, > > there are things that one cannot express using the current pointcut > syntax. > > > > For instance, I would like to declare a pointcut that matches any method > > with only the primitive parameters. The current syntax does not allow me > to > > do so, does it? I can write something like this: > > > > pointcut aaa() : execution(* *.*((int || double || char), (int || double > || > > char), (int || double || char), ..)); > > > > But I need to list all the primitive types and create several versions of > > this pointcut for methods with 0, 1, 2, 3, etc arguments until some > > reasonable number. > > You can write: > > pointcut aaa(): execution(* *.*(!Object+,..)); > > > > Does it make more sense now? > > Now you've described your use case, I can see what you want. Indeed I > did temporarily have a back door for this in an old version. The > requirement was that the set of modifiers was extensible and you could > plug in a class that defined what matching your modifier meant. In > the case I remember supporting, the modifier was 'trivial' and the > definition of a trivial method was 'a short one less than 20 > instructions with no branches in it'. > > pointcut methodsToTrace(): execution(!trivial * *(..)); > > This meant we could avoid tracing getters/setters, that kind of thing. > > Now I think I've taken support out for that now, but a while later > Spring came along with the first class notion of a 'bean'. This led > to making the pointcut parser extensible so that matching could be > done on 'bean'. I am not sure how well publicized this interface was > though, I just know Spring is using it, I don't recall if you can pass > in your new designators on the command line though, would need to look > at the code. Spring has no problem with that because it creates the > pointcut parser directly rather than calling 'ajc'. > > Andy > > > ------------------------------ > > Message: 8 > Date: Wed, 14 Dec 2011 13:48:52 -0800 > From: Andy Clement <[email protected]> > To: [email protected] > Subject: Re: [aspectj-users] Why annotations are not exposed through > JoinPoint.StaticPart? > Message-ID: > <CAAu=NOkk8JN=HotnwS9RVA3ELfjdmO5x8Qq817+=+z6fanu...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > The code to build the JoinPoint static part objects is generated at > compile/weave time. Basically the static initializer in your class > becomes a big long list of joinpoint create calls. Adding annotations > to the mix would just mean that the reflective calls to fetch them for > inclusion in the joinpoint object would be made in your static > initializers (or possibly lazily when requested), since, as I say, you > can't new up annotations in an easy way. Effectively we would just be > moving the reflective calls around, they'd still be made. > > Andy > > On 14 December 2011 13:41, Mark <[email protected]> wrote: > > So, basically it is only available through the reflection on the > respective > > type/method/field? But, since they are indeed available during the > > compilation, you could have cached them in thisJoinPointStaticPart? > > > > I would really like this feature, so here you go - > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=366757 > > > > Thanks. > > > > -- > > View this message in context: > http://aspectj.2085585.n4.nabble.com/Why-annotations-are-not-exposed-through-JoinPoint-StaticPart-tp4196637p4197179.html > > Sent from the AspectJ - users mailing list archive at Nabble.com. > > _______________________________________________ > > aspectj-users mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > ------------------------------ > > Message: 9 > Date: Wed, 14 Dec 2011 14:04:33 -0800 (PST) > From: Mark <[email protected]> > To: [email protected] > Subject: Re: [aspectj-users] Why annotations are not exposed through > JoinPoint.StaticPart? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > OK, let me repeat, because I am slow. There is some internal AspectJ code > that runs during the compilation. This code can know what the annotations > are and theoretically could have injected the following code into the > static > constructor: > > typeAnnotations = new Annotation[2]; > typeAnnotations[0] = new TypeAnnotation1("yaba daba doo"); > typeAnnotations[1] = new TypeAnnotation2(3); > > for a type annotated like so: > > @TypeAnnotation1("yaba daba doo") > @TypeAnnotation2(3) > public class MyType {} > > But "one can't new up annotations in an easy way", which I interpret as > "one > cannot have a code like the above". > > If I have grokked you correctly, then this is sad. Java annotations are not > like C# attributes after all. > > -- > View this message in context: > http://aspectj.2085585.n4.nabble.com/Why-annotations-are-not-exposed-through-JoinPoint-StaticPart-tp4196637p4197257.html > Sent from the AspectJ - users mailing list archive at Nabble.com. > > > ------------------------------ > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > End of aspectj-users Digest, Vol 82, Issue 18 > ********************************************* >
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
