Re: [equinox-dev] Breaking change for Luna Equinox Weaving: IWeavingServ

[Stephan Herrmann <stephan.herrmann@xxxxxxxxx>]

Hi Martin,

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
> implementations simultaneously.

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
> handles caching)
>
> - 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?

cheers,
Stephan