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