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"
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