[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