[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Integrating AspectJ Load-Time Weaving into OSGi/Eclipse
- From: Matthew Webster <matthew_webster@xxxxxxxxxx>
- Date: Fri, 23 Sep 2005 17:33:07 +0100
- Delivered-to: firstname.lastname@example.org
- Importance: Normal
>This is correct. But I think you can use this approach for the opt-in
>model as well. Don't you?
It depends whether you consider the model to be one of packaging, intent or
effect :-). I presume you mean that using AJEER I can package my LTW aspect
with the bundle it affects. Also that by tailoring the pointcuts
appropriately I ensure only the classes in my bundle are woven. However
using the supplements approach you can guarantee only the co-opted bundle
is affected regardless of packaging or pointcuts.
>As Peter points out the weaving creates additional dependencies between
Rather than considering the dependencies to be a side affect of the weaving
the new headers declare the need for particular bundles or packages which
happen to contain aspects. One advantge of this approach not yet
implemented is the ability to target specific versions of a bundle.
Java Technology Centre, MP146
IBM Hursley Park, Winchester, SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
Martin Lippert <lippert@xxxxxxx>@eclipse.org on 20/09/2005 22:19:42
Please respond to Equinox development mailing list
Sent by: equinox-dev-bounces@xxxxxxxxxxx
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Subject: Re: [equinox-dev] Integrating AspectJ Load-Time Weaving
> The AJEER project offers a very simple approach to declaring aspects
> the Eclipse plug-in mechanism. One or more aspects are packaged in a
> and declared through an extension point provided by the weaving
> 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
> first class entities packaged in bundle fragment or library bundles.
> 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
> 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.
equinox-dev mailing list