[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[aspectj-users] AJHotDraw v 0.4 errors
|
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,
<aspectj-users-request@xxxxxxxxxxx> wrote:
Send aspectj-users mailing list submissions to
aspectj-users@xxxxxxxxxxx
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
aspectj-users-request@xxxxxxxxxxx
You can reach the person managing the list at
aspectj-users-owner@xxxxxxxxxxx
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 <mark.kharitonov@xxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users] AspectJ vs PostSharp?
Message-ID: <1323890261149-4196604.post@xxxxxxxxxxxxx>
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 <mark.kharitonov@xxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users] Why annotations are not exposed through
JoinPoint.StaticPart?
Message-ID: <1323890858289-4196637.post@xxxxxxxxxxxxx>
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 <andrew.clement@xxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] AspectJ vs PostSharp?
Message-ID:
<CAAu=NOnW3uNZmCPD2Hdsn19KVwZk94L1SF-8yY3gGwtezLV2vA@xxxxxxxxxxxxxx>
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 <mark.kharitonov@xxxxxxxxx> 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
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
------------------------------
Message: 4
Date: Wed, 14 Dec 2011 13:21:21 -0800
From: Andy Clement <andrew.clement@xxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Why annotations are not exposed through
JoinPoint.StaticPart?
Message-ID:
<CAAu=NOkuX0A_6ky3B7bBoFR6=GUapC_A4i43khVnDepgE8CpRQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
On 14 December 2011 11:27, Mark <mark.kharitonov@xxxxxxxxx> 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 <mark.kharitonov@xxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] AspectJ vs PostSharp?
Message-ID: <1323897717255-4197102.post@xxxxxxxxxxxxx>
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 <mark.kharitonov@xxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Why annotations are not exposed through
JoinPoint.StaticPart?
Message-ID: <1323898907814-4197179.post@xxxxxxxxxxxxx>
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 <andrew.clement@xxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] AspectJ vs PostSharp?
Message-ID:
<CAAu=NO=2ihVKm9DO8hspDrv5dysDwHmicBQUfcRHVm34GwSp3Q@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1
On 14 December 2011 13:21, Mark <mark.kharitonov@xxxxxxxxx> 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 <andrew.clement@xxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Why annotations are not exposed through
JoinPoint.StaticPart?
Message-ID:
<CAAu=NOkk8JN=HotnwS9RVA3ELfjdmO5x8Qq817+=+z6FanuX1A@xxxxxxxxxxxxxx>
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 <mark.kharitonov@xxxxxxxxx> 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
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
------------------------------
Message: 9
Date: Wed, 14 Dec 2011 14:04:33 -0800 (PST)
From: Mark <mark.kharitonov@xxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Why annotations are not exposed through
JoinPoint.StaticPart?
Message-ID: <1323900273246-4197257.post@xxxxxxxxxxxxx>
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
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
End of aspectj-users Digest, Vol 82, Issue 18
*********************************************
