[
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
|
Very interesting!
However, the headers worry me :-( This could work fine in an
environment where we all trust each other. However, the OSGi (and as I
understand in the future Eclipse) should also be able to run in secure
mode.
From you description I understand that the weaving creates
dependencies that are unknown to the weaved (woven?) bundle. I.e. the
generated classes can link to classes outside the bundle's class
space?
Adding headers seems to be redundant (and hard) because you know exactly when you
weave what kind of dependencies you create. Why can't you add those
packages during runtime? These packages could be treated as dynamic
imports for the runtime class loading engine. This would minimize the
dependencies (which is always better) and seems much simpler.
But maybe I misunderstood. I want to get started with this, do you
have some advice what is the best route to get start playing with this
technology?
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
