[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.equinox] Re: AspectJ-enabled runtime implementation 
Hi,

I haven't tried out so many different use cases for improving the Eclipse implementation using AspectJ. But one thing I used as an example is an aspect that logs calls any methods inside the eclipse jdt core package from within the control flow of a specific method. This kind of cflow dependent logging could be realized pretty easily via AspectJ.

For example:

public aspect MethodCallAspect {

pointcut methodexecutions(): execution(void *.*(..));
pointcut insideSomething(): cflow(execution(void org.eclipse.jdt.core.dom.CompilationUnit.setPackage(..))
&& within (org.eclipse.jdt.core..*));

before(): methodexecutions() && insideSomething() && within(org.eclipse.jdt.core..*) {
System.out.println("execution entering " + thisJoinPoint.getSignature());
}
}

This could be written inside a separated plugin without modifing or recompiling the jdt core classes using the AspectJ-enabled Eclipse core runtime.

Just one stupid example, but it might illustrate the possibilities.

Best regards,
Martin





pkriens wrote:

The things I would like to do with (dynamic) AspectJ are:

- Debugging and tracing
- Usage of things people should not use in a shared environment
    - System.out/err/in
    - Adding URL handlers themselves (this is a one time op)
    - System.exit
    - ...
- Preventing stale references (or diagnosing)
- Security
- Authorization

Kind regards,

    Peter Kriens

Jeff McAffer wrote:

I second Peter's interest.  It would also be interesting to have some
usecases to motivate this in a plugin setting.

Jeff

"pkriens" <Peter.Kriens@xxxxxxxx> wrote in message
news:3E87FE7E.3090406@xxxxxxxxxxx

I think it is a great idea to see if this weaving could be done in
runtime. It is something I discussed at the OOPSLA 3 years ago with the
AspectJ people but I then understood it weaving could basically only be
done with the sources.

I seen several applications in the OSGi world where this might be very
useful. Unfortunately, aspect oriented programming is not very well
known among embedded developers (and there are of course the size
impacts). Can you describe more in detail the API you would need from
the class loaders to make this possible? Or do you have pointers to
papers? I'd like to propose this to some of the OSGi vendors.

Thanks, kind regards,

Peter Kriens

Martin Lippert wrote:


Hi all,

my name is Martin (Lippert) and I am new to this group. Brian Barry and
Jeff (McAffer) told me that this might be the right place to talk about
my ideas. So I hope you are interested in it, even if it might sounds a
bit strange at first sight.

During the last weeks and months I had the idea of bringing AspectJ and
the Eclipse plugin model closer together by allowing people to develop
applications using both, aspects written in AspectJ and plugins using
the Eclipse runtime. They would be able to write aspects in AspectJ,
compile them with their compiler (or the respective plugin for the Java
Tooling inside Eclipse) and plug them into the system as a normal
plugin. The main motivation is that people are interested in both:
plugins as their base runtime infrastructure and aspects to modularize
crosscutting concerns.

I thought about load-time weaving to allow them to individually develop
each plugin. Today, they can use an aspect only inside a single plugin,
because the compiler weaves the aspect into the other classes. With
load-time weaving the idea of Eclipse to encapsulate each plugin (even
with aspects that define cross-plugin pointcuts) would become possible
for aspects.

So I implemented a modified version of the core plugins (boot and
runtime) to realize this behavior and demonstrated it at the AOSD
conference last week. The feedback was very positive and I would like to
continue to improve the implementation and make it available to the
people who are interested.
The only thing that makes this a bit complicated is the fact that I had
to implement a modified version of the base plugins. It was not possible
to write a plugin that enhances the runtime in the way I want it to be.

The main reasons for this:
- I had to inject the weaving at class-loading time. The current class
loader of Eclipse do not allow me to enhance their behavior for such
kind of things.
- I had to add dependencies between plugins at runtime (depending on
which aspect got woven into which class).
- I had to add some setup code that got called after the registry is
initialized but before the application starts.

And this is exactly the point where it might be interesting for this
project. These are exactly the points where I would love to make the
runtime more flexible. This might seem a bit strange (especially the
load-time modifications of classes), but the load-time weaving of
aspects opens a totally new world of possibilities for aspects and
plugins used together.

So I am highly interested in hearing your opinions on that. I can also
provide more technical details of the possible enhancements to the
runtime. I would also love to contribute some code for this kind of
modifications, if possible. What do you think?

Best regards,
Martin Lippert


---
Martin Lippert
email: lippert@xxxxxxx