[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re[2]: [equinox-dev] Integrating AspectJ Load-Time Weaving into OSGi/Eclipse
|
MW> How does a secure OSGi operate? What is it designed to protect against?
MW> Does it use signed JARs/bundles? Remember that LTW does not offer any
MW> additional capability over static binary (post-compile) weaving except
MW> greater flexibility. Are you concerned that bundle providers need to
MW> protect themselves against modification?
OSGi security is based on Java 2 security. However, we added lots of
class loading relation permissions. One such security aspect is that a
bundle requires permission to use other packages. That is, the package
name space is managed.
For the rest, it is standard Java and VERY applicable to the work you
do. One issue with the protection mechanisms we have build in is that
it is not always the easiest to program. However, most of the grudge
work is boilerplate and seems extremely well suited to AOP. (Finally a
good use case except debugging! :-)
MW> LTW can be used weave aspects that are declared in packages already
MW> imported or required by a bundle: one of the goals of this approach is to
MW> make the use of aspects as similar to classes as possible. However the
MW> side-affect of weaving is a new dependency on the (small) AspectJ runtime
MW> which must be added to the "class space": using Require-Bundle semantics
MW> allows aspect bundles to transparently re-export the necessary packages.
MW> Furthermore capabilities in completely new packages can also be introduced.
That is what I understood. The weaving creates new depenencies. We
must carefully engineer this so that security and convenience does not
go out of the window.
MW> The Supplement-Bundle/Importer/Exporter is both a configuration mechanism
MW> and a means for the resolver to extend the set of dependencies for a
MW> bundle. In the same way a bundle provider selects classes through
MW> Import-Package or Require-Bundle header an aspect bundle provider selects
MW> the target bundles with a Supplement header. WRT it being hard we have a
MW> working version ;-).
Yes, I know it can be done. The question is if this is the most
convenient way ... Convenience is crucial in these matters. We spent
an insane amount of time specifying the current headers :-( it is
surprising how many things you interfere with.
MW> We should be able to make an OSGi patch available at some point for others
MW> to try out the technology.
Great, if you make a core framework available that can weave (and an
example app), then I'd love to look at it and write about it in my
blog.
However, I had 3 questions that you did not answer :-)
1. How do I get started in Eclipse 3.1 with AOP
2. Should we standardize an interface so that Oscar and Knopflerfish
can also provide this functionality?
3. Can you calculate the dependencies when you do the weaving? If that
is true, we should have an API to add the dependencies to the class
loader.
Thanks! Kind regards,
Peter Kriens
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/
MW> Peter Kriens <Peter.Kriens@xxxxxxxx> on 19/09/2005 17:53:29
MW> Please respond to pkriens <Peter.Kriens@xxxxxxxxx>
MW> To: Matthew Webster/UK/IBM@IBMGB
MW> cc: equinox-dev@xxxxxxxxxxx, "Richard S. Hall" <heavy@xxxxxxxxxxxxxx>
MW> Subject: Re: [equinox-dev] Integrating AspectJ Load-Time Weaving into
MW> OSGi/Eclipse
MW> Very interesting!
MW> However, the headers worry me :-( This could work fine in an
MW> environment where we all trust each other. However, the OSGi (and as I
MW> understand in the future Eclipse) should also be able to run in secure
MW> mode.
MW> From you description I understand that the weaving creates
MW> dependencies that are unknown to the weaved (woven?) bundle. I.e. the
MW> generated classes can link to classes outside the bundle's class
MW> space?
MW> Adding headers seems to be redundant (and hard) because you know exactly
MW> when you
MW> weave what kind of dependencies you create. Why can't you add those
MW> packages during runtime? These packages could be treated as dynamic
MW> imports for the runtime class loading engine. This would minimize the
MW> dependencies (which is always better) and seems much simpler.
MW> But maybe I misunderstood. I want to get started with this, do you
MW> have some advice what is the best route to get start playing with this
MW> technology?
MW> Kind regards,
MW> 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
MW> calling
MW>> AOSGi to compare the two approaches to supporting AspectJ load-time
MW> 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
MW> 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
MW> an
MW>> Eclipse environment. However they differ greatly in the way that
MW> aspects
MW>> are declared and how the set of bundles affected is determined. The
MW> 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
MW> 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
MW> 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
MW> 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
MW> 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
MW> using
MW>> the Eclipse plug-in mechanism. One or more aspects are packaged in a
MW> bundle
MW>> and declared through an extension point provided by the weaving
MW> mechanism.
MW>> Essentially it offers a global co-op model with target classes
MW> determined
MW>> by pointcuts only. It doesn't exploit AspectJ 5 LTW configuration
MW> through
MW>> aop.xml files because it predates that mechanism.
MW>> AOSGi is designed to be a natural extension to both AspectJ LTW and
MW> OSGi.
MW>> It uses AspectJ 5 aop.xml files to declare aspects and the OSGi
MW> component
MW>> model to determine the scope of any weaving. Just like AJEER aspects
MW> can be
MW>> first class entities packaged in bundle fragment or library bundles.
MW> AOSGi
MW>> supports both the co-opt and opt-in models with the latter using
MW> proposed
MW>> extensions to the current bundle manifest headers. A draft
MW> specification
MW>> that describes this in more detail is attached.
MW>> I think the approaches are complementary and we should try to support
MW> both
MW>> using a single weaving runtime. This runtime will intercept class
MW> 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
MW> how
MW>> to plug the different configuration mechanisms into a single weaving
MW>> runtime, possible using a OSGI service. The same applies to the
MW> 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
MW> 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
MW> 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
MW> a
MW>> particular bundle are determined using the normal class loader search
MW> 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
MW> it
MW>> depends.
MW>> To support the opt-in model no changes to the existing OSGi
MW> 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
MW> extend a
MW>> super-aspect defined in another bundle in which case the fragment
MW> manifest
MW>> must include the appropriate Require-Bundle or Import-Package header.
MW>> This approach allows the host bundle to remain unchanged and the
MW> 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
MW> available
MW>> it will not be loaded, no weaving will occur and the host will behave
MW> 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
MW> defines
MW>> one or concrete aspects and the necessary aop.xml file. The bundle
MW> 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
MW> all of
MW>> the exported packages (Export-Package:) of the supplementing bundle
MW> added
MW>> to its classpath. The semantics are the same as if the supplemented
MW> 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
MW> all of
MW>> the exported packages (Export-Package:) of the supplementing bundle
MW> added
MW>> to its classpath. The semantics are the same as if the supplemented
MW> 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
MW> 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.
MW> 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,
MW> 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
MW> 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/
MW> --
MW> Peter Kriens Mob +33633746480
MW> 9C, Avenue St. Drézéry Tel +33467542167
MW> 34160 Beaulieu, France Tel +15123514821
MW> Tel +33870447986
MW> AOL,Yahoo, Skype pkriens ICQ 255570717
--
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
