Community
Participate
Working Groups
If multiple weavers should ever work on top of the same caching service, the key used for caching would need to be composed from contributions by each weaver. Currently, the WeavingAdaptorFactory creates a caching service only for one weaving service, using only the getKey() of this one weaving service. I don't know what else might need changing for multiple weavers, but without combined cache keys the caching service will not be able to properly work with multiple weavers. I'm reporting this against equinox weaving / caching 1.0.100, but also for a potential rewrite using the new weaving hooks I suggest to consider multiple weavers from the start. At the level of the old adapter hooks, weavers are actually independent, but this independence doesn't help for caching.
Can we do something to fix weaving so that OTDT works with Aspectj and ScalaIDE out of the box? I would like to help, but I'm not sure I understand what caused this issue in the first place. Anyhow, I would really like to see this issue fixed. Martin, Stephan, if you have any pointers I would appreciate it.
Thanks, Ivica, for bringing this up again. While for the next 2 weeks I'll be mostly busy getting some fixes into JDT in time for Kepler M7, I'm more than happy to discuss with you if/how you could indeed help in this area. I understand that equinox.weaving is currently being worked on to accommodate pending API changes in the equinox framework. Please see the thread starter in the mailing list at http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg07460.html You may want to skim through the links and the discussion that followed. For a start, you might want to ask where (in which repo) this work is happening. Getting the latest source of equinox.weaving should be a good start in any case :) @Martin: could you please provide a link to your repo/branch? For cross-reference: the original motivation for this RFE can be found in bug 351085 comment 24. The bottom line being: a cached (woven) class could be woven by one or more weavers. Whether or not re-weaving should happen is decided based on keys generated by a weaver. I found no way how these keys can currently be used to distinguish the cases of "woven by one weaver" vs. "woven by all interested weavers". Thus my suggestion was to use compound keys within the caching service. I kind of remember Martin suggesting another (simpler) solution, but unfortunately memory fails me wrt any details. Martin, do you remember?
Hi Hermann, meanwhile I've forked rt.equinox.bundles objectteams git repos and started poking around the source code. Correct me if I'm wrong but at the moment objectteams doesn't use weaving service, nor caching service?
(In reply to comment #3) > Correct me if I'm wrong but at the moment objectteams doesn't use weaving > service, nor caching service? You're right. We have our own adaptor hooks, but I'm willing to work on migrating to those services. Let me dig out my previous experiments. My idea is to start with a simplified integration of the OT/J weaver to leverage the weaving service. Much of our current complexity deals with ensuring correct order of loading, weaving, instantiating, activating. For experiments regarding caching we can probably use a much simpler implementation of the weaving integration. Note that the entry into actual byte code transformations is org.eclipse.objectteams.otre.jplis.ObjectTeamsTransformer which has the standard signature defined by java.lang.instrument.ClassFileTransformer. thanks, Stephan
Two quick notes: (1) Discussion on the general strategy re equinox.weaving is happening at http://dev.eclipse.org/mhonarc/lists/equinox-dev/ (2) First experiments in re-implementing OT/Equinox on top of the new WeavingHook from the OSGi spec (instead of Equinox specific hooks) are looking very promising. I'll push those to a feature branch before the end this week.
(In reply to comment #5) > Two quick notes: > > (1) Discussion on the general strategy re equinox.weaving is happening at > http://dev.eclipse.org/mhonarc/lists/equinox-dev/ > > (2) First experiments in re-implementing OT/Equinox on top of the new > WeavingHook from the OSGi spec (instead of Equinox specific hooks) > are looking very promising. I'll push those to a feature branch > before the end this week. This is great news, do you have bug number we can follow the progress on for OT?
(In reply to comment #6) > This is great news, do you have bug number we can follow the progress on for > OT? Thanks for asking, I just started bug 406518 for this purpose. A feature branch will be pushed after some cleanup...
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
