[
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
|
Peter,
>One more thing. Is it possible to have a short discussion so that this
>model also works in Knopflerfish and Oscar?
Certainly. Do you mean here on the list. There are 2 elements to the
current suggestion: an OSGi service used by the adaptor/class loader to
request weaving and the extended manifest headers. The latter is only
required to support the co-opt model.
Matthew Webster
AOSD Project
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
http://w3.hursley.ibm.com/~websterm/
Peter Kriens <Peter.Kriens@xxxxxxxx> on 19/09/2005 19:30:46
Please respond to pkriens <Peter.Kriens@xxxxxxxxx>
To: Matthew Webster/UK/IBM@IBMGB
cc: equinox-dev@xxxxxxxxxxx
Subject: Re: [equinox-dev] Integrating AspectJ Load-Time Weaving into
OSGi/Eclipse
One more thing. Is it possible to have a short discussion so that this
model also works in Knopflerfish and Oscar?
If the open source community standardizes it, then I can try to get
this accepted as an OSGi standard.
Kind regards,
Peter Kriens
MW> I have been looking at AJEER
MW> (http://sourceforge.net/projects/ajeer) and
MW> what the AspectJ team (http://eclipse.org/aspectj/) are currently
calling
MW> AOSGi to compare the two approaches to supporting AspectJ load-time
weaving
MW> (http://www.eclipse.org/aspectj/doc/next/adk15notebook/ltw.html) in the
MW> OSGi/Eclipse environment. Both approaches enhance class loading at the
OSGi
MW> level (by replacing the Framework Adaptor) to facilitate byte-code
MW> modification and allow aspects to be treated as first class entities in
an
MW> Eclipse environment. However they differ greatly in the way that
aspects
MW> are declared and how the set of bundles affected is determined. The
goal of
MW> this analysis is to develop a single implementation of AspectJ LTW in
MW> Eclipse/OSGi.
MW> Independently of the Eclipse/OSGi environment AspectJ offers two
different
MW> models for applying aspects. Using the "opt-in" model an application
MW> developer writes their own aspect or customizes one provided in a
libarary
MW> through the implementation of a concrete sub-aspect or using Java 5
MW> annotations. The co-opt model allows someone other than the application
MW> developer to write a concrete aspect that implements a
platform-specific
MW> integration feature or a problem diagnosis capability, package it in a
MW> bundle and affect applications in the system without requiring them to
be
MW> modified in any way. Both models are supported by AspectJ load-time
MW> weaving. Both models are applicable to the OSGi environment where an
MW> application is represented by one or more bundles.
MW> The AJEER project offers a very simple approach to declaring aspects
using
MW> the Eclipse plug-in mechanism. One or more aspects are packaged in a
bundle
MW> and declared through an extension point provided by the weaving
mechanism.
MW> Essentially it offers a global co-op model with target classes
determined
MW> by pointcuts only. It doesn't exploit AspectJ 5 LTW configuration
through
MW> aop.xml files because it predates that mechanism.
MW> AOSGi is designed to be a natural extension to both AspectJ LTW and
OSGi.
MW> It uses AspectJ 5 aop.xml files to declare aspects and the OSGi
component
MW> model to determine the scope of any weaving. Just like AJEER aspects
can be
MW> first class entities packaged in bundle fragment or library bundles.
AOSGi
MW> supports both the co-opt and opt-in models with the latter using
proposed
MW> extensions to the current bundle manifest headers. A draft
specification
MW> that describes this in more detail is attached.
MW> I think the approaches are complementary and we should try to support
both
MW> using a single weaving runtime. This runtime will intercept class
loading
MW> for each plug-in, determine which aspects are declared to affect the
MW> plug-in and call AspectJ to perform the necessary weaving. A optional
MW> byte-code caching service should also be provided. We need to discuss
how
MW> to plug the different configuration mechanisms into a single weaving
MW> runtime, possible using a OSGI service. The same applies to the
byte-code
MW> caching. Enhancments to the existing AspectJ WeavingAdaptor will be
MW> required to override the use of aop.xml files.
MW> AOSGi - Supporting AspectJ Load-Time Weaving in OSGi
MW> Byte-code weaving is achieved by replacing the default Framework
Adaptor
MW> with one that intercepts class loading for each bundle and invokes the
MW> AspectJ weaver. The weaver is configured using standard AspectJ 5
aop.xml
MW> files, each packaged in the bundle containing the concrete aspects it
MW> declares. The set of configuration files, and hence aspects, visible to
a
MW> particular bundle are determined using the normal class loader search
order
MW> for resources: ClassLoader.getResources(aop.xml). This means that a
MW> bundle is only woven with aspects that are defined in bundles on which
it
MW> depends.
MW> To support the opt-in model no changes to the existing OSGi
implementation
MW> are required. An AspectJ bundle fragment is created that both defines a
MW> concrete aspect and the accompanying aop.xml file. The aspect may
extend a
MW> super-aspect defined in another bundle in which case the fragment
manifest
MW> must include the appropriate Require-Bundle or Import-Package header.
MW> This approach allows the host bundle to remain unchanged and the
fragment
MW> to be omitted from a deployment when the aspects it contains are not
MW> needed. In addition if a bundle required by the fragment is not
available
MW> it will not be loaded, no weaving will occur and the host will behave
as
MW> normal. This feature is particularly useful when using optional
MW> capabilities that may not be available in a particular installation.
MW> To use the co-opt model an aspect library bundle is created that
defines
MW> one or concrete aspects and the necessary aop.xml file. The bundle
manifest
MW> is used to declare which bundles will be affected by the aspects. The
MW> proposal is to extend the manifest to support three new headers:
MW> * Supplement-Importer
MW> * Supplement-Exporter
MW> * Supplement-Bundle
MW> These are analogous to the existing Import-Package, Export-Package and
MW> Require-Bundle attributes, but they invert the dependency. These
MW> additional attributes have the following syntax and semantics:
MW> Supplement-Importer: PackageSpecificationPattern [,
MW> PackageSpecificationPattern]*
MW> Where PackageSpecificationPattern is any valid OSGi package
MW> specification (as used in an Import-Package attribute) but with the
MW> addition that wild cards are allowed (*,..) in the package name.
MW> Every bundle that imports a package matched by a
MW> PackageSpecificationPattern in the Supplement-Importer attribute has
all of
MW> the exported packages (Export-Package:) of the supplementing bundle
added
MW> to its classpath. The semantics are the same as if the supplemented
bundle
MW> specified a Require-Bundle header naming the supplementing bundle.
MW> Supplement-Exporter: PackageSpecificationPattern [,
MW> PackageSpecificationPattern]*
MW> Every bundle that exports a package matched by a
MW> PackageSpecificationPattern in the Supplement-Exporter attribute has
all of
MW> the exported packages (Export-Package:) of the supplementing bundle
added
MW> to its classpath. The semantics are the same as if the supplemented
bundle
MW> specified a Require-Bundle header naming the supplementing bundle.
MW> Supplement-Bundle: BundleNamePattern [, BundleNamePattern]*
MW> Where BundleNamePattern is the name of an OSGi bundle (as used in
the
MW> Require-Bundle: attribute) but with the addition that wild cards are
MW> allowed (.,..,*) at the end of bundle names only (e.g.
MW> Supplement-Bundle: org.eclipse.*)
MW> Every bundle whose name is matched by a BundleNamePattern in the
MW> Supplement-Bundle attribute has all of the exported packages
MW> (Export-Package:) of the supplementing bundle added to its classpath.
The
MW> semantics are the same as if the supplemented bundle specified a
MW> Require-Bundle header naming the supplementing bundle. Note that the
MW> supplementing mechanism will not allow a bundle to supplement itself,
or
MW> any bundles on which it depends.
MW> The affect of using one or more of these new headers is that both the
MW> aop.xml configuration and the declared aspects contained by the library
MW> bundle will be visible to target bundles. No changes to those bundles
are
MW> required and if the co-opting bundle is excluded from a deployment no
MW> weaving occurs.
MW> Matthew Webster
MW> AOSD Project
MW> Java Technology Centre, MP146
MW> IBM Hursley Park, Winchester, SO21 2JN, England
MW> Telephone: +44 196 2816139 (external) 246139 (internal)
MW> Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
MW> http://w3.hursley.ibm.com/~websterm/
--
Peter Kriens Mob +33633746480
9C, Avenue St. Drézéry Tel +33467542167
34160 Beaulieu, France Tel +15123514821
Tel +33870447986
AOL,Yahoo, Skype pkriens ICQ 255570717
