[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Integrating AspectJ Load-Time Weaving into OSGi/Eclipse

Hi all,

The AJEER project offers a very simple approach to declaring aspects using
the Eclipse plug-in mechanism. One or more aspects are packaged in a bundle
and declared through an extension point provided by the weaving mechanism.
Essentially it offers a global co-op model with target classes determined
by pointcuts only. It doesn't exploit AspectJ 5 LTW configuration through
aop.xml files because it predates that mechanism.

This is correct. But I think you can use this approach for the opt-in model as well. Don't you?

Of course we cannot use the extension mechanism on the OSGi level to let bundles contribute aspects. I agree that the aop.xml files seem to be the natural choice here.

AOSGi is designed to be a natural extension to both AspectJ LTW and OSGi.
It uses AspectJ 5 aop.xml files to declare aspects and the OSGi component
model to determine the scope of any weaving. Just like AJEER aspects can be
first class entities packaged in bundle fragment or library bundles. AOSGi
supports both the co-opt and opt-in models with the latter using proposed
extensions to the current bundle manifest headers. A draft specification
that describes this in more detail is attached.

As Peter points out the weaving creates additional dependencies between bundles. AJEER takes care of those new dependencies by identifying which aspects are actually woven into a bundle (this information is provided by the AspectJ weaver). Then the appropriate packakes are added dynamically to the DynamicImport declarations of the woven bundle.

(This is what Peter suggested ???)

I think the approaches are complementary and we should try to support both
using a single weaving runtime. This runtime will intercept class loading
for each plug-in, determine which aspects are declared to affect the
plug-in and call AspectJ to perform the necessary weaving. A optional
byte-code caching service should also be provided. We need to discuss how
to plug the different configuration mechanisms into a single weaving
runtime, possible using a OSGI service. The same applies to the byte-code
caching. Enhancments to the existing AspectJ WeavingAdaptor will be
required to override the use of aop.xml files.

Some more details on the AJEER implementation:

- AJEER creates separate weaver instances for each bundle. This is done to ensure that the type resolution for the weaver matches exactly the class loading of the bundle.

- AJEER implements a byte-code caching mechanism to skip the time-consuming weaving task if nothing has changed (same bundle version, same aspect version, same set of aspects).

Therefore AJEER is separated into two bundles: the first one enhances the OSGi framework adaptor to intercept class loading and takes care of the byte-code cache. It provides a hook for other bundles to inject bytecode modifier components. The second bundle injects the AspectJ weaver as a bytecode modifier component.