Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] equinox weaving w/ caching and other weavers 
Hey Stephan!
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.
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, but that would mean to re-implement the OTDT weaving on top of equinox weaving, which doesn't make much sense, I think.
The obvious right step would be to re-implement the caching service to work with the new weaving hooks and provide a good caching for those weavers (and therefore also multiple weavers). This isn't done yet, I think. At least I haven't worked on it - and I guess it is not completely trivial. But I just haven't found the time to work on this.
Once this caching service would be in place, we would need to re-implement the AspectJ weaver on top of the new weaving hook API, but that should not be that complicated. 

Just my 2 cents,
Martin



we've been discussing this long time ago, and now some users are finally
bugging me that they want to run OTDT and AJDT in the same eclipse
instance. At a first look both weaving mechanisms (built using the same
adaptor hooks) actually play well together, with minor hickups only,
but after restarting eclipse the class file cache kills the OTDT :)
(Not expecting to see already woven classes we'll add our stuff for
a second time =>  boom).

Question is: what would be needed to integrate a second weaver with
the caching infrastructure?

At a first glance I thought I could just check if the class bytes being
loaded already contain our stuff, and if so just skip weaving.
However, I don't know how to check cache validity. It seems there is
no explicit cache invalidation, but rather the cache will just grow
with new directories with new hash-names, right? (No cleanup, ever?)

From that it seems I would have to integrate with the mechanism

for computing fingerprints, but the actual computation of the finger
print is burried inside o.e.e.weaving.aspectj, and this doesn't seem to
be open to add more elements to the finger print.

I saw some activity to migrate the weaving service to the new standard
API. Has it been decided yet, how the caching service will fit into that
picture? Will it have to be redesigned, too?

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?

thanks,
Stephan


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Back to the top