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