[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Breaking change for Luna Equinox Weaving: IWeavingServiceFactory.createWeavingService takes a BundleDescription
- From: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
- Date: Tue, 23 Apr 2013 17:45:56 +0200
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
On 04/23/2013 05:10 PM, Martin Lippert wrote:
The current work is going on in the twatson/container branch of the
rt.equinox.bundles repository. This is the place where we made the
changes to run that on top of the new framework implementation. And this
would be the place that I would propose to implement further
improvements and changes.
The downside is that the implementation there works on the new framework
only (coming in Luna), but I would like to avoid the need to change two
I totally agree, let's just work towards Luna, and not waste our time
working in two different branches simultaneously.
The basic design idea was:
- we have a number of weavers
- we have one caching service
The key for the cache is partly generated by the weaver to let the
weaver decide what should be part of this key. This is important for the
AspectJ weaving, for example, because the weaving service stays the
same, but the woven aspects might change over time (new aspect bundles
installed, old aspect bundles uninstalled). Therefore the weaver
generates that key.
Exactly, except for all occurrences of "weaver" in the singular :)
Each weaver should have a chance to signal that a particular cached
class is out-of-date, right?
In case any weaver vetoes the cached class, all weavers must be
invoked again with the original class bytes, right?
Once I'll dive deeper into this, we may need one more concept:
some persistent weaver state. The reason is: our weaver issues globally
unique IDs used in the woven code. When re-weaving only some of the
previously woven classes, we need a means to ensure that the use
of these IDs remains consistent.
Would such concept make sense of the AJ weaver, too, or should
OT/J handle this on its own?
The relation to the key-issue would be: I'd like to generate keys
in a way that allows to identify the corresponding weaver state,
that was used while weaving the cached class file.
I think there are two strategies (that come to my mind):
- re-implement the OT/J weaver to use the equinox.weaving service
interface and therefore plug that into that infrastructure (that also
- or re-implement both weavers on top of the OSGi weaving hook and
re-implement the caching to allow it to cache those results.
The first option might be easier to implement (and less work), the
second one would be a better solution, I think. It would be much more
aligned with the OSGi spec and Equinox would "just" provide some
additional value due to the caching.
The second option would need some kind of additional interface between
the weavers and the caching (maybe implement or register an additional
service) so that the caching can retrieve those kind of "key"
information from the weavers (and maybe more). But that is just a vague
idea at the moment.
What do you think?
I'm just now starting to explore the new WeavingHook.
It'd be way cool to migrate to that, for sure.
With the Equinox specific hooks we had a very luxurious environment,
with lots of events to react to, thanks to Tom! :)
Have you assessed, whether this one hook would be sufficient for AJ?
Let me play a little with both variants, before I make any promises :)
BTW, is there any additional documentation on WeavingHook beside
the JavaDoc and the ECon 2011 presentation by Tim Ward?