Re: [equinox-dev] equinox weaving w/ caching and other weavers

[Stephan Herrmann <stephan@xxxxxxxxxxxxxxx>]

Hi Martin,

thanks for your quick response. Meanwhile I've found some time for
experiments, which raised new questions :)

> The quick solution here would be to disable the caching service for
> equinox weaving. This can be done by stopping the bundle (or avoid to
> have it auto-started). If the caching bundle is not active, no caching
> happens and everything is freshly woven at startup every time.

What would I recommend to users here? 
Edit configuration/org.eclipse.equinox.simpleconfigurator/bundles.info?
That seems to do the trick, just wondering if there's also a simpler flag.
 
> The caching service was designed to work with the old equinox weaving
> implementation and is able to invalidate the cache when the weaving
> service produces a different key for the cache. If I remember this
> correctly, this also works with multiple weaving services, 

I can't see how the fingerprints/keys from multiple weaving services would
be combined.

That's why I thought additional API may be needed here:

> > How about an additional service like
> > 
> >        String getFingerprintAddon(Bundle base)
> > 
> > Then I could register an implementation of the service that encodes
> > all OT/Equinox bundles that weave into the given base bundle,
> > I could even add the weaver version into that string,
> > and the caching service would collect all answers from all these
> > services for computing the total finger print. What do you think?
> > 
> > Should I file a bug or do you have a better idea?

For multiple weavers on top of the same caching service we'd need some
way of combining a fingerprint from different contributions, no?

I'm currently fighting a bug that happens because some classes are woven
by both weavers, and here the cached version will be used but classes woven
only for OT are not cached. Since the OT weaver generates some globally 
unique IDs used for dispatching, classes re-used from the cache and freshly
woven classes will use inconsistent sets of IDs. Boom.

Next I tried to explicitly store OT-woven classes using the existing caching
service, but since OT isn't involved in generating the keys for caching,
an empty key will be used and thus these classes are NOT cached. :(

Is there a quick hack how I could tell the caching service that I do have
changes in some classes?

Otherwise, we'll just have to stick with disabling caching in this 
constellation.

best,
Stephan