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

[Martin Lippert <lippert@xxxxxxx>]

Hi Jeff,

> > 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.
> >    
>
> Do you see any impact here if the plugin structure (i.e., registry) is
> dynamic?  Rather than addImport() it may be that the registry entries
> themselves need to be updated.
Also possible. But for me the dependencies seems to be of two different 
kinds:
- statically defined dependencies between plugins, as defined in the 
plugin.xml
- dynamically created dependencies via bytecode modification. Those 
dependencies cannot be statically defined within the plugin.xml files.

In addition to that using bytecode modifications might introduce cyclic 
dependencies between plugins. In the current Eclipse plugin model cyclic 
dependencies between plugins are not allowed (which makes perfectly 
sense to me). But the cyclic dependencies between introduced, for 
example by aspect weaving seem reasonable for me, too.

Therefore I am not sure whether the registry should allow cyclic 
dependencies in general. The add-import method for the class loader was 
my first idea to allow cyclic dependencies between plugins on the 
dynamic level without violating the registry model of non-cyclic plugin 
dependencies.


>  
>
> > 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.
> >    
>
> yup. Typical bootstrap problem.    How do you deal with system classes?  For
> example, by the time you get to loaderStartup() lots of system classes like
> String have been loaded.  Is there a technique in the AOP bag o tricks to
> catch these as well?
I do not know of any tricks that AOP provide to solve these bootstrap 
problems (which might not mean that there don't exist some). For my 
modified runtime it was perfectly reasonable to disable aspect weaving 
for the boot/runtime plugins. Therefore the weaving works for all other 
plugins, only. In addition to that I am not sure if it makes sense to 
allow this kind of self-modification...

>  
>
> > Any opinions on that?
> >    
>
> Very powerful.  Of course, very dangerous too.  Are there any security or
> permissions techniques in the AOP world that would help control this
> capability?
I don't think so. I thought of letting plugins define themselves as 
"sealed" or something similar. Then the runtime would not allow any 
bytecode modifications of those plugins. But that was just a first idea.

> In terms of mechanics, what is invovled in writing a bytecode transformer?
> does AspectJ/AJDT do this for you?
>  
The bytecode modifications for the AspectJ integration is completely 
implemented inside the AspectJ project (mainly from Erik Hilsdale, I 
think). They use bytecode modifications to implement their compiler (the 
compiler works in two steps: 1. compile the sources 2. weave the 
compiled code). I just use exactly the weaving functionality of the 
AspectJ compiler and call this from my specific class loader (which I 
contributed to the AspectJ project).

Best regards,
Martin