| Re: [equinox-dev] Integrating AspectJ Load-Time Weaving into OSGi/Eclipse |
Martin, >To emulate the AJEER setting I would need to put an aspect into a bundle >and define the header somehow like this: >Supplement-Bundle: * >Would this mean that the aspect would be woven with every other class in >all bundles (if the aop.xml file allows this)? Yes, although it would be good to maintain the simplicity of the current AJEER configuration by doing this under the covers. >And a second question regarding the co-opt mechanism: >If I define an aspect inside a bundle A which advices all >implementations of a specific interface (which is defined in another >bundle) I would need to define the affected bundles via the supplement >headers within the manifest of the bundle that contains the aspect. Is >this correct? And if someone contributes a new bundle (not known to the >aspect bundle deleveloper) I would need to adjust the supplement >definition to include this bundle for the weaving of that aspect? It depends. The use of wildcards may make this unnecessary. Also the Supplement-Importer/Exporter header might be more appropriate. >P.S. and BTW: How does the supplement mechanism relates to the buddy >mechanism from your point of view? It's the inverse i.e. you declare who regards you as their buddy. Also because it has the semantics of Require-Bundle the package resolution has a higher priority. 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/ Martin Lippert <lippert@xxxxxxx>@eclipse.org on 29/09/2005 20:50:47 Please respond to Equinox development mailing list <equinox-dev@xxxxxxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx> cc: Subject: Re: [equinox-dev] Integrating AspectJ Load-Time Weaving into OSGi/Eclipse Hi Matthew, I think I now understand the goal of your manifest headers better. Thanks for that. Just some more questions to ensure that I have understood it correctly. ;-) To emulate the AJEER setting I would need to put an aspect into a bundle and define the header somehow like this: Supplement-Bundle: * Would this mean that the aspect would be woven with every other class in all bundles (if the aop.xml file allows this)? And a second question regarding the co-opt mechanism: If I define an aspect inside a bundle A which advices all implementations of a specific interface (which is defined in another bundle) I would need to define the affected bundles via the supplement headers within the manifest of the bundle that contains the aspect. Is this correct? And if someone contributes a new bundle (not known to the aspect bundle deleveloper) I would need to adjust the supplement definition to include this bundle for the weaving of that aspect? -Martin P.S. and BTW: How does the supplement mechanism relates to the buddy mechanism from your point of view? > They are operating at different levels of abstraction, require different > skill levels and can be used by different people. > > The pointcut is used by the aspect author. Whoever deploys an aspect bundle > may not have the necessary skill or even the source code to modify the > scope of an aspect. They could however customize the behaviour using > aop.xml but it doesn't understand bundles only classes and packages: to > determine which bundles to affect they would have to inspect which packages > they defined. Using the Supplements mechanism someone who understands OSGi > can easily tailor and aspect bundle to only affect the desired bundles in > the system. > > 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/ > > Martin Lippert <lippert@xxxxxxx>@eclipse.org on 20/09/2005 22:26:27 > > Please respond to Equinox development mailing list > <equinox-dev@xxxxxxxxxxx> > > Sent by: equinox-dev-bounces@xxxxxxxxxxx > > > To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx> > cc: > Subject: Re: [equinox-dev] Integrating AspectJ Load-Time Weaving > into OSGi/Eclipse > > > Matthew, > >> 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 ;-). > > Could you help me here? I think I am a bit confused about the point > where the possibly affected target classes/bundles are defined... So > basically the question is: What is the relation between pointcuts, the > weaver options in the aop.xml file and the supplement definitions? > > Thanks!!! > > -Martin > > > _______________________________________________ > equinox-dev mailing list > equinox-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > _______________________________________________ > equinox-dev mailing list > equinox-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > _______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev
Attachment:
smime.p7s
Description: Binary data