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

[Martin Lippert <lippert@xxxxxxx>]

Hi Mel,

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

Yes, in the case of the bytecode transformer components the runtime gets 
a new extension point to let other plugins implement transformers.

Then I would implement my AspectJ addition to the runtime as a single 
plugin. This plugin itself defines an extension point for aspects. Using 
this extension point other plugins would be able to provide aspect 
implementations and promote them to the complete system. The pointcut is 
defined inside an aspect. The pointcut is a named set of join points, 
where a joinpoint is a point in the execution of the system. For example 
the execution of a specific method is a concrete join point. A pointcut 
might be defined using wildcards or other things. That means, that I do 
not need to name the concrete class a join point might belong to.

For example:

public aspect MethodCallAspect {
 pointcut methodexecutions(): execution(void *.*(..)) && within 
(org.eclipse.jdt.core..*);
 ...
}

This defines a pointcut named methodexecutions. The pointcut describes a 
set of join points (all method executions with the return type void 
inside org.eclipse.jdt.core and all subpackages (the AspectJ language 
allows you to define these join point models with a huge number of 
powerful designator constructs. Those a really powerful, I think).

Transferred to the plugin runtime a join point model might describe 
concrete points that belong to different plugins without naming them 
directly inside the aspect. Therefore the specific class loader has 
first to determine of the class to be loaded contains any join points of 
any aspects that are promoted to the system via the new extension point.

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

Correct.

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

As far as I know the AspectJ language does not define any kind of 
security mechanisms. I thought of a special kind of "sealing" for 
plugins. Then a plugin could define in the plugin.xml that it is a 
sealed plugin and that no bytecode modifications should be applied to 
it. But that was just a first thought on this topic.

Best regards,
Martin





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