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

just one word before I start to explain the modifications. I have implemented a modified version of the Eclipse runtime which allows you to define aspects in single plugins. As long as the aspects are promoted via a special extension (to a new extension point) that got woven into the complete system if defined so in the pointcut definition of the aspect. The current implementation is based on Eclipse 2.1 RC2 and AspectJ 1.1rc1 and it really works. So if anybody would like to see and try it, just drop me an email.

And now some more details on what I would like to have to implement the dynamic weaving inside a separate plugin (currently it is directly injected into the boot and runtime plugins):


Bytecode modification at class loading time:
--------------------------------------------
A new extension point that allows me to declare bytecode transformer components inside a plugin. The extension point could be defined by the boot or the runtime plugin. Which one to take depends on whether the boot or the runtime plugin should include a modification to the class loader to call possible extensions (bytecode transformers) before the loaded bytecode is given to the VM.

Extension Point definition:

Something like:
<extension-point name="%bytecodetransformerName" id="bytecodetransformers"/>

Interface for the extension point:

public interface BytecodeTransformer {

public byte[] transformBytecode (Resource classResource, String pluginId);

}

(The classResource parameter is used to get the real bytecode as well as the URL from where the bytecode is loaded. The plugin id parameter is used to let the bytecode transformer component know to which plugin the class belongs that got modified. This information is used to handle the dependencies between the plugins, see next point.)

To realize this kind of transformer extension point the runtime or boot plugin has to implement the class loading directly inside the Eclipse specific class loaders instead of delegating it to the JDK URLClassLoader superclass. This is necessary because the URLClassLoader does not allow a subclass to inject functionality while the bytecode of a class is loaded.


Handling dependencies between plugins dynamically:
--------------------------------------------------
While aspects are woven into classes (of possibly each plugin) new dependencies between plugins might be introduced. This has to be put in place by the bytecode transformer when it happens. Therefore the bytecode transformer needs some kind of method “addImport” at the DelegatingURLClassLoader.


Initialization of the transformer components:
---------------------------------------------
The transformer components have to be initialized before the real application is started by the runtime (to make sure that the bytecode modification reaches all classes of the system, except boot and runtime of course). Currently I coded this into the InternalPlatform’s loaderStartup method.


Any opinions on that?


Best regards,
Martin



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