[
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,
How does a secure OSGi operate? What is it designed to protect against?
Does it use signed JARs/bundles? Remember that LTW does not offer any
additional capability over static binary (post-compile) weaving except
greater flexibility. Are you concerned that bundle providers need to
protect themselves against modification?
LTW can be used weave aspects that are declared in packages already
imported or required by a bundle: one of the goals of this approach is to
make the use of aspects as similar to classes as possible. However the
side-affect of weaving is a new dependency on the (small) AspectJ runtime
which must be added to the "class space": using Require-Bundle semantics
allows aspect bundles to transparently re-export the necessary packages.
Furthermore capabilities in completely new packages can also be introduced.
The Supplement-Bundle/Importer/Exporter is both a configuration mechanism
and a means for the resolver to extend the set of dependencies for a
bundle. In the same way a bundle provider selects classes through
Import-Package or Require-Bundle header an aspect bundle provider selects
the target bundles with a Supplement header. WRT it being hard we have a
working version ;-).
We should be able to make an OSGi patch available at some point for others
to try out the technology.
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 17:53:29
Please respond to pkriens <Peter.Kriens@xxxxxxxxx>
To: Matthew Webster/UK/IBM@IBMGB
cc: equinox-dev@xxxxxxxxxxx, "Richard S. Hall" <heavy@xxxxxxxxxxxxxx>
Subject: 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
