[
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?
Cheers,
-Martin
