Hello,
See comments below...
2008/7/21 100ji <
itz100ji@xxxxxxxxx>:
> Hi all,
>
> I am working on a research project. Boradly, the project is just a
> fancy logging application that should log specified fields in
> specified types at specified point cuts. All the things that should
> be specified are fed as an xml file to my python script which performs
> the following tasks:
>
> a) reads an XML file to construct the point cuts
> b) for each of these point cuts I only need to log some specific data
> for a specific type from the exposed context. I modify the advice to
> log those specific parts along with the name of the join point using
> thisJoinPoint.
> c) finally all these generated strings are concatenated and written to
> an aspectj file.
> d) the generated aspectj file is used to instrument an existing application.
>
> I have the following questions: I looked at the ltw-configuration
> page[1] in the manual, but it didn't seem to answer these questions:
>
> generating aspectj files:
>
> 1) Is there a better way to generate these aspectj files?
For building AspectJ source files you could try using the Ast
support to generate aspects but I'm not sure it
currently supports construction of all the elements of a pointcut
down to the level you probably like to use. Or you could generate
annotated source using the annotation style @Before/@After annotations.
Of course either of these would still leave with source that needed compiling.
There is no mechanism for direct creation of the bytecode form of
the aspect. If you are asking about something to help you build the aop.xml
files, I don't think there is anything right now.
> 2) I saw that I can specify the point cuts using aop.xml file. But I
> see that the aop.xml files are generated from the ajc. So, is it a
> common practice to write aop.xml files? Are there any tutorials on how
> to write aop.xml files?
The aop.xml files generated by the compiler are just very basic simple
ones that list the aspects - they are only for use when no further customization
is necessary (eg. further concretization of abstract aspects).
The doc you linked describes everything that can go into an aop.xml file.
> 3) Can I use aop.xml files to perform compile time weaving?
No, see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=124460 which
discusses using aop.xml to control weaving whenever it is done.
> 4) Can I specify advice in aop.xml file?
No, it is just for concretization of abstract pointcuts.
> 5) Also, can someone explain, the concrete and abstract aspects and
> how all of it related to aop.xml files?
Abstract aspects may contain abstract pointcuts. Advice attached to
these abstract pointcuts cannot be applied anywhere until the
pointcut is fully defined in a concrete sub-aspect. Because a concrete
sub-aspect may be trivial, we support defining it directly in XML, within
aop.xml. Here is an example, first the abstract:
abstract aspect TraceAspect {
abstract pointcut scope();
before(): execution(public * *(..)) && scope() {
System.out.println("Entering "+thisJoinPoint);
}
}
Now the choices for concrete aspect:
public aspect TracePackageFoo extends TraceAspect {
pointcut scope(): within(foo..*);
}
OR
<!-- define a concrete aspect inline -->
<concrete-aspect name="TracePackageFoo"
extends="TraceAspect">
<pointcut name="scope" _expression_="within(foo..*)"/>
</concrete-aspect>
>
> building projects:
>
> 6) The generated aspectj files, should be applied to random java
> projects I download from internet. Is load time weaving the best way
> to apply those aspects? I can't use compile time weaving since it
> requires messing with the build files of those random java projects
> which is hard. Can I implement ltw using command line options ( I use
> makefiles, so this options is important)? What is the general way to
> do things like this?
I might use binary weaving against the .jars that make up what you have
downloaded, but loadtime weaving should be OK. Remember that ltw
will only weave the code that is exercised in what you run, whilst
binary weaving will weave everything regardless of whether it is
exercised in a particular application run. This can make a difference
depending on whether you are observing the weaver output messages
(-showWeaveInfo).
With ltw you have to run something and include the AspectJ java agent,
so for these random projects you download you will need to have something to run
or you will have to write a driver program that drives the behaviour you want to trace.
> Performance:
>
> 7) During each point cut I need to log the name of the pointcut in the
> file for which I am using thisJoinPoint. If I generate a single
> pointcut and advice for each of the functions I am interested in, will
> it make my program any faster since thisJoinPoint is slow?
Two kinds of information may be captured in a thisJoinPoint object - static
fixed information (eg. what method is this, what line am I on) or dynamic changing
information (eg. what are the current parameter values). If you only use the static
information then thisJoinPoint is not expensive since it is built once at class load
for the advised locations - but if you use the dynamic information then it has to be
built for every advice call, and that can be expensive.
---
You don't necessarily need to create the aop.xml directly if you write your own
weaving context for aspectj (implementing IWeavingContext) since then you just
need to give AspectJ what it is expecting (the information that would have been
retrieved from the XML). However, the documentation on doing this is, errr, not
very good.
From your description of the scenario, I might be tempted to use binary weaving.
cheers,
Andy.
>
> TIA,
> -S-
>
> [1]
http://www.eclipse.org/aspectj/doc/released/devguide/ltw-configuration.html
> _______________________________________________
> aspectj-users mailing list
>
aspectj-users@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
