[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Breaking change for Luna Equinox Weaving: IWeavingServiceFactory.createWeavingService takes a BundleDescription

Hey Stephan!

May I join the party? :)

You are very welcome!!! Would be great to have you on board for this!!!

In https://bugs.eclipse.org/358290 we have a candidate interested
in helping to make the caching service capable to handle multiple
independent weavers.

Martin, could you please share your current implementation as a
common starting point for future experiments? Or should we still
work from master of equinox.weaving and friends?

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 remember you saying that the cache-key issue shouldn't actually
be an issue, but unfortunately I don't remember your reasoning,
only remember that in my experiment it was a problem :)

To be honest, I don't remember all the details either... ;-) So we should take a fresh look at this... :-)

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.

The caching service hooks into the framework storage and delegates classloading bytecode retrieval to the caching service (to avoid duplicate bytecode loading from disc).

While currently the OT/J weaver is not based on equinox.weaving
but our own adapter hooks I'd like to use the opportunity while
this topic is in people's heads to help work on a future solution.

Yepp, lets do this.

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?