LTW via OSGi in Eclipse 2024-03 plugins is not working #57
Comments
urferr
changed the title
|
I am using the update site https://download.eclipse.org/tools/aspectj/ajdt/431/dev/update. The problem described in eclipse-aspectj/aspectj#49 i had also before it has been fixed. Now AJDT works fine but my additional aspects don‘t
|
|
Then please, publish a minimal reproducer on GitHub. I cannot debug what I cannot see, compile and run. |
|
Hi, I will join your report as I have similar issue. I've described my problem on stackoverflow if you want to see it. Here is the example Eclipse product which can be build by maven Oh, and by the way, this issue only affects windows platform, its working fine on my Kubuntu distro. |
How do I launch the application? I built the project from the command line successfully. Now, what are the next steps? Warning: I am unexperienced in all things Tycho, Eclipse plugins and OSGi. It might surprise you, but I only use as much of these as is minimally necessary to compile AJDT. I actually have no idea how they work. So please, tell me what to do to reproduce the problem. Update: I also do not know how to correctly import the project into Eclipse. Normally, I do not use Eclipse. |
|
Sorry, I forgot to specify all the steps required to reproduce the issue. If maven build is finished, you should have the eclipse application built in following directories: And then if you open the Error Log view ( |
|
Yeah, I see it. But sorry, how am I supposed to debug this? The application is complex (it seems to be a customised Eclipse IDE or some kind of RCP application of size ~320 MB. I have no idea where to start looking for the root cause of the problem. I also cannot see where and how LTW is used there. Don't you have a small example project which I can simply run from an existing Eclipse 2024-03 IDE installation? It is intransparent to me what is going on under the hood here. You also seem to use |
|
Upgrading the plugin dependency to |
Note to myselfOne possible problem source could be the fact that Eclipse IDE (and with it our dependency JDT Core) is released before the support for the next Java version is merged to the main branch, e.g. https://github.com/eclipse-jdt/eclipse.jdt.core/commits/R4_31/ from Feb-17. I.e., AspectJ, being urged by its users to always support the latest Java version but also the latest Eclipse version, always merges later commits, typically right after the new Java beta branch has been merged into the JDT Core main branch. In this case, we merged this version: That corresponds to https://github.com/eclipse-jdt/eclipse.jdt.core/commits/b2705b00e91be7 from Mar-20. I.e., in the meantime classes like One possible workaround would be to recommend to users to upgrade their Eclipse installations (or the versions used for building RCP applications or similar) to an Eclipse integration build a close as possible to the merge point, similarly to the recommendations for 2023-12 in https://github.com/eclipse-aspectj/aspectj/blob/master/docs/developer/IDE.md (see the screenshot after the sentence "Your AspectJ-related list of Eclipse update sites could look like this for Eclipse 2023-12"). How to determine the corresponding I-build for the latest JDT Core merge
In this case, the "0620" build does not have any repositories, but the "0740" one does. Therefore, https://download.eclipse.org/eclipse/updates/4.32-I-builds/I20240320-0740/ should be the correct update site for Eclipse. |
|
@urferr, @k-mierzej If you add https://download.eclipse.org/eclipse/updates/4.32-I-builds/I20240320-0740/ as an update site to your Eclipse IDE or Tyhco build, respectively, does it fix the problem? In Eclipse, you should run IDE updates from that update site and restart the IDE first. An alternative would be to install Java 22 support from the Eclipse marketplace: https://marketplace.eclipse.org/content/java-22-support-eclipse-2024-03-431. That might also help and would, according to the marketplace entry description, correspond to update site https://download.eclipse.org/eclipse/updates/4.31-P-builds/. |
|
@kriegaex, I've used the update site, but that didn't change anything. You've focused on compatibility of versions, but is that even possible, given the fact that the same configuration does work on Linux distro? We have like 20+ jdt and compiler modifications and no problems on linux. I don't think I am able to provide smaller example, those projects which I've uploaded can be imported to Eclipse IDE but some additional plugins would be needed to run them correctly. Maybe the reporter will add some additional feedback. EDIT. I've managed to set up eclipse IDE on my windows and launched the |
|
@k-mierzej, please describe as well as you can how and where you use LTW. Like I said, I see CTW in your build config. Are you using |
|
@k-mierzej, I have just remembered the name of the other weaving thingy: Equinox Weaving. Maybe whoever maintains that, needs to adjust it to the latest AspectJ changes, if they use weaver classes that otherwise are mostly used by the AspectJ Weaver itself. |
|
I've created the ticket in equinox GitHub eclipse-equinox/equinox#584 @kriegaex I'm afraid I don't know the answers to your questions because I initially thought that the aspect included in the example project was LTW. I didn't create these aspects in our project; I'm simply trying to update our product to the latest Eclipse version. My knowledge about AspectJ is very limited. EDIT. As far as I understand, the Eclipse plugin |
|
I have now created a simple Aspectj plugin which, when added to a dropins folder of an Eclipse 2024-03 installation will prevent the Eclipse IDE from being started. A zip file containing the plugin is attached. Here the minimal steps to reproduce the problem
|
Thank you, @urferr. I see that the plugin also contains source files which look strikingly similar to the ones in the aspect module of @k-mierzej's GitHub project. Does your plugin - I have not tried it yet - also work on Linux and fail on Windows like the other one? Please also provide a GitHub source for this minimal plugin. Thank you. BTW, I just tried running @k-mierzej's GitHub project on Windows Subsystem for Linux and can reproduce the behaviour that it is working there. It proves that weaving as such is working. The different behaviour on Windows and Linux might be caused by a class-loading issue. I have no idea how to debug this. But maybe - and this is pure speculation - the same classes are provided by several plugins or classloaders, and for some reason maybe one of them is woven, but then another unwoven one used. I wish I had an idea how to debug that. Maybe you two can help there. You seem to have way more Eclipse expertise than I do. I really appreciate your collaborative spirit, both of you. Another question: Do you know each other or work together? Your use cases look so similar. |
kriegaex
changed the title
|
@kriegaex We do not know each other. I found this issue randomly, and since the original reporter did not provide an example, I decided to speed up the issue resolution by adding mine. I suppose this is a common use case of AspectJ in Eclipse plugin development, which is why they are somewhat similar. As for debugging it in Eclipse IDE, I believe it may be extremely challenging because when I ran the plugin directly from my IDE instead of the Tycho-built product, it worked fine. If you want to run my example from another Eclipse IDE, you'll need to import those projects, but first, you'll need to install three additional Eclipse plugins. I think I could prepare the instructions, but it's somewhat pointless if the issue is not reproducible then. |
kriegaex
added
bug
|
When transferring the issue from AspectJ to AJDT, at least one of my comments vanished. So, I am writing it again in a similar way. I had a suspicion that OSGiWeavingAdaptor::defineClass might be the root cause of the problem, because it tries to use After enabling a trace, I can see this on the console when starting @k-mierzej's project on Windows: This happens, because AJDT still uses a copy of the old AspectJ weaver code. I think, this can be solved by delegating to the super class, but the two existing
|
Call ClassLoaderWeavingAdaptor::defineClass. TODO: For 2024-06 (4.32), make ClassLoaderWeavingAdaptor::defineClass protected and call it via super instead of duplicating class definition code or hackily calling a private method via reflection. Fixes #57.
I committed the workaround and published a new AJDT version on the 4.31 update site. @urferr, @k-mierzej, please re-test and report back. For me, it works with @k-mierzej's RCP product, I already tested locally. BTW, you do not need the I-build Eclipse update site either. Strictly speaking, it would be necessary for another small fix I made locally due to a small breaking change in Eclipse since 2024-03, but this is out of scope here. |
Relates to eclipse-aspectj/ajdt#57 and it a precondition for refactoring phase 2 of child class OSGiWeavingAdaptor::defineClass, which can now directly call the super methods instead of using reflection. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
In my case, it looks like the issue is resolved, thank you @kriegaex |
|
@urferr, is there any chance that your plugin wants to weave classes too early in the process of starting the IDE, before AJDT and Equinox AspectJ weaving support are ready? Does maybe your plugin need any extra settings for stuff it depends on, so Eclipse OSGi wires it correctly? Can you please tell me how I can set log levels to see more? I am really an Eclipse noob, I would appreciate your advice. I double-checked, the IDE definitely contains the latest AJDT build with the updated |
|
For the record: The IDE does not even start, and there is a whole bunch of exceptions. The last one before failing to start looks like this: |
|
Another note to myself: Could this be about The open question is why Eclipse is trying to find class |
|
The test plugin is completely easy, it just add an around advice to the method org.eclipse.core.internal.resources.ProjectDescription.setNatureIds(String[]) and proceeds the call. Unfortunately i also don't know how to enable more logging in eclipse which could help to analyze the problem. I also have now upgraded several of my development environment to eclipse 2024-03 with the latest AJDT plugin version and all are working fine. I did not have any errors so far. But everywhere i first deleted the existing eclipse installation and created a new one instead of just upgrading the existing one. |
|
I am happy it is working for you. For me, it is not, maybe due to other installed plugins or other config peculiarities. That means, it could fail again for others, which leaves me with an uneasy feeling. I would not require users to always install Eclipse from scratch only to upgrade AJDT. |
|
I installed AJDT and the test plugin in a fresh 2024-03 workspace. At first, it worked, but after creating an AspectJ project, playing around with it and restarting the IDE, it started failing again. @urferr, maybe your solution IDE also starts failing after a while. Please, let me know. After deleting the workspace and starting over, I could start the AspectJ project creation wizard, but when I changed some settings in the wizard (JRE execution environment changed to 1.8 with JDK 22), the error occurred while the wizard was still open. I.e., the AJDT bugfix does not seem to work everywhere for reasons I do not understand. All I know is that there are no AspectJ or AJDT classes in the stacktrace, other than the generated |
|
After deleting the workspace and restarting Eclipse, I see this:
The error goes away, if I remove the drop-in plugin. |
|
Strange. but it seems that is has something to do with data cached under eclipse/configuration. I tried now again with the test system i was successful this morning and this was now suddenly not working anymore even i did not touch it since this morning. Then i have deleted the .metadata folder in the workspace and started eclipse again. Starting was successful but i could not import the project anymore. When i tried it always failed with missing ProjectDescription.$AjcClosure1. Next i have deleted everything und eclipse/configuration except the folder org.eclipse.equinox.simpleconfigurator and the file config.ini. Starting eclipse was successful and now i could also import the projects again and the loadtime weaving works fine. Unfortunately i am not familiar with the content of eclipse/configuration except the folder and the file i did not delete but i assume it has something to do with the org.eclipse.osgi folder and its content. Now i have create a Java class and an Aspect stop the eclipse ide and wanted to start is again and have the problem. After deleting the eclipse/configuration/org.eclipse.osgi folder i could start the eclipse ide again. So the problem seems really be in some data store under the eclipse/configuration/org.eclipse.osgi. Most probably the equinox guys know what is stored under this folder. |
|
My expectation was not completely correct. As soon as i create a new java class in any project i cannot start the eclipse ide anymore after closing it. I always have to delete the folder eclipse/configuration/org.eclipse.osgi to make it working again. |
|
Thanks for these details. That sounds similar to my experience. Maybe we should reopen the other issue over there again. |
|
I just found a workaround but then starting eclipse ide is much slower. If you add -Dosgi.clean=true to the eclipse.ini in the part of the vm arguments then it seems that this cache is always recreated even a log file is created under eclipse/configuation with the following content: !SESSION 2024-04-05 16:48:46.444 ----------------------------------------------- !ENTRY org.eclipse.osgi 4 0 2024-04-05 16:48:47.001 |
|
@kriegaex I haven't tried the example myself, but while reading through this the caching service comes to my mind. The basic idea is: if you weave aspects on every startup of the IDE, it is really slowing things down significantly and causing quite some additional memory to be consumed. Therefore, the idea is to cache the woven classes and let the weaving service use those cached woven class bytecodes when a class is loaded. This should - of course - be kept around until something changes (like new aspects being installed, plugins being upgraded, etc.). If you want to debug into this, the fundamental caching logic is implemented in https://github.com/eclipse-equinox/equinox/tree/master/bundles/org.eclipse.equinox.weaving.hook. The concrete storage of the cached bytecode in files is implemented in https://github.com/eclipse-equinox/equinox/tree/master/bundles/org.eclipse.equinox.weaving.caching Why is this in different bundles and abstracted via an ICachingService? The reason is that we had a J9 JVM specific caching implemented back then as well, which used J9-specific API to cache bytecode. Otherwise, the caching wouldn't have worked when running on J9 (back then). I have no concrete idea in mind what exactly might be going wrong here, but your problem descriptions sound like something in the caching area. But that implementation hasn't really changed since years, so I wonder why the basic caching should suddenly break - since it is completely independent of the way the AspectJ weaving is done. The caching itself is independent of the concrete weaving logic, whether it is AspectJ doing weaving or something else, so I wonder how those changes in the AspectJ weaving service implementation could affect this, but those are more questions than answers... :-) |
@martinlippert, I think I am in way over my head here already. I need help. Can you please help me? I am offering to directly collaborate with you in a debugging session with desktop sharing. I can contribute some AspectJ and AJDT and you some Equinox weaving/caching knowledge. Otherwise, this is going to take too much time, and I will probably not look into it, because I see little chance to sort this out by myself. |
|
@xpomul, you lately contributed some caching fixes both to AJDT and Equinox. Can you maybe take a look what is happening here, please? Your contributed |
|
Update: I deployed an AspectJ 1.9.23 snapshot with some small changes. They do not fix the problem, but help in debugging and running tests. If you check out branch e431, the build will use that version. |
|
@xpomul, reverting eclipse-aspectj/aspectj#278 fixes your test, but not the problem in real life. eclipse-aspectj/aspectj@8a4aa03 seems to influence the result. Can you advise me how to adjust AJDT to that change? |
|
@kriegaex I will try to find some time tomorrow to check out the issue. |
This was introduced in commit 8a4aa03 of PR #278 contribution as part of the #279 fix. The contributor thought that the generated closure class entries were never used, but in fact AJDT class OSGiWeavingAdaptor relies on the presence of those entries. To the best of my present knowledge, it looks as if this change was the root cause of eclipse-aspectj/ajdt#57. Therefore, I reverted it, simultaneously refactoring Iterator::remove usage to delete entries from the map to Collection::removeIf. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
This was introduced in commit 8a4aa03 of PR #278 contribution as part of the #279 fix. The contributor thought that the generated closure class entries were never used, but in fact AJDT class OSGiWeavingAdaptor relies on the presence of those entries. To the best of my present knowledge, it looks as if this change was the root cause of eclipse-aspectj/ajdt#57. Therefore, I reverted it, simultaneously refactoring Iterator::remove usage to delete entries from the map to Collection::removeIf. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
@urferr, @k-mierzej: I might have found the root cause. It seems to be a premature optimisation in a recently contributed PR to AspectJ, which I have reverted. Please try with the AJDT version I have just published on the 4.31 update site. The version number should be @martinlippert, I hope I will not need your help anymore. @xpomul, I would be glad if you would review this. As you can see, I also changed something in |
|
I am closing this issue, because I think it is fixed. In case of negative re-testing feedback we can reopen it again. For the record, we had two separate problems here:
|
|
Have retested all my eclipse ide installations and it looks fine. Thanks @kriegaex |
Directly added a comment to the commit: 84c7931#commitcomment-140770901 |
We use an aspectj plugin to weave some classes in the eclipse IDE. This was working fine until eclipse 2023-12 but now with eclipse 2024-03 its failing. I have also installed the latest version of AJDT but this did not solve the problem. For all the classes there exists an aspect for we get now the following error:
For me this looks like classes are not generated by the loadtime weaver.
The text was updated successfully, but these errors were encountered: