[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Equinox Aspects CachingService
|
Thomas Watson schrieb:
> Hi Matthew, Martin and all other Equinox Aspects freaks,
> 1. I doubt that caching can be implemented using
> ClassLoadingStatsHook.recordClassDefine() like in AspectJHook.
> ClasspathManager.findClassImpl() calls recordClassDefine() with the
> orignial byte[], not with the woven one. Therefore
> ICachingService.storeClass() will be passed the useless original
byte[],
> weaving will not be cached.
> I suggest placing the caching calls into AspectJHook.processClass()
> after the weaving calls.
>
This has been fixed by
https://bugs.eclipse.org/bugs/show_bug.cgi?id=167824
in 3.2.2. What version of Eclipse are you testing? The correct
woven bytes are now passed to recordClassDefine.
Tom
Thank you Tom!
I should have talked to Martin :-)
I am using 3.2.2 but I took org.eclipse.osgi_3.2.0 from the Equinox
Aspects CVS repository => I guess it should be deleted there!
That was nuber 1. But what about 2..4.?
2. I wonder if AspectJAdaptor.shouldWeave() ever returns false.
I checked with a modified implementation of AspectJHook (see 1.) where
my caching seemed to work but after loading the woven class (from cache)
sholdWeave() returned true.
Is this magic method surely working correctly? Could anone please
explain that "first four bytes logic" of shouldWeave() to me?
3. ICachingService.getInstance() and IWeavingService.getInstance() seem
strange design to me.
This is mixing of concerns. Once the caller (Activator of implementing
bundles) expects the implementations to be singleton factories, and once
something different.
Why not refactor getInstance() to ServiceFactories and let only these
ServiceFactories be OSGi services (singletons)?
4. The method ICachingService.hashNamespace() is never used externally,
thus can be removed from the interface. Right?
Heiko
