[news.eclipse.technology.equinox] Re: AspectJ-enabled runtime implementa

[Mel Martinez <melm@xxxxxxxxxx>]

Martin,

Please excuse any ignorance revealed in my comments since while a long 
time OO dog, I'm a virtual babe when it comes to aspect oriented 
programming.

Martin Lippert wrote:
> 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.

SO this would be a new extension point for the runtime that would allow 
other plugins to define bytecode transformations applied by the 
classloader when loading particular plugins defined in the 'pointcut' 
for an aspect?  pointcut == a set of plugins ?

The bytecode transformations are used to 'mix-in' dynamically the 
defined aspect?  Right?

This sounds incredibly powerful and useful.

Obviously, the chief concerns that jump out are security concerns.  What 
does AspectJ itself provide or reommend to address security considerations?

This of course re-iterates why I think it is paramount that Eclipse 
plugins gain some sort of security sandbox model.



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

These dependencies need to be tracked with the potential for dynamic 
load/unload of plugins in mind, of course.