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

All sounds cool/interesting.  see my comments...

"Martin Lippert" <lippert@xxxxxxx> wrote in message
news:b6cj17$1fe$1@xxxxxxxxxxxxxxxx

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

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

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

In terms of mechanics, what is invovled in writing a bytecode transformer?
does AspectJ/AJDT do this for you?

Jeff