Community
Participate
Working Groups
Hi, I have the situation where I have shared eclipse installations, which means users don't have write-access to the profile/installation. The profiles are setup for cascaded config.ini files. The problem with weaving is that the enable/disable option in the preference page does not honour that case. It only tries to set the parameters in the global config.ini which is bound to fail. So basically weaving can't be switched from the preference page in a shared installation scenario. thx M;chi
Are you talking about the "JDT Weaving" preference page?
(In reply to comment #1) > Are you talking about the "JDT Weaving" preference page? yep
This is part of the AJDT development, I move this bug over to them.
Hi Andrew! As far as I remember our discussions and ideas on how to control the enabling/disabling of the weaving, I thought we moved to starting and stopping the service without modifying the config.ini. Am I wrong here?
So, the main way of enabling/disabling weaving is through starting and stopping the equinox weaving bundle. However, when enabling weaving, I also ensure that the weaving hook line is in the config.ini. This is where it is failing for Michael. I can change things such that the check is done, and if the weaving hook line does not exist and the file is read-only, a warning is displayed, rather than a failure.
Michael, Does the global config.ini contain the line: osgi.framework.extensions=org.eclipse.equinox.weaving.hook (or something like it)? Does your local config.ini contain it? If this is a shared installation, then are users able to install their own plugins?
OK. Just made a small change to the way that weaving enablement occurs. 1. Set the weaving.aspectj bundle to autostart. 2. Check the global config.ini for the hook line 3. Add if necessary and not read-only 4. If should add, but read only issue a warning to the user, and restart anyway. I can make further changes to check for the hook line in the local config.ini, but I'd like to first see if this works.
And new dev build will be available in a few hours.
(In reply to comment #6) > Michael, > > Does the global config.ini contain the line: > osgi.framework.extensions=org.eclipse.equinox.weaving.hook > (or something like it)? > > Does your local config.ini contain it? When I add it manually as root, yes > If this is a shared installation, then are users able to install their own > plugins? No
OK. The build is available. The way it is with this new build, you will receive a warning if the hook line is not in the config file, but the weaving bundle will still be activated. Note that both are required in order for the weaving service to be enabled. When Equinox Aspects is installed through p2, the hook line will be added to the config.ini in the proper way. However, I don't know how you installed AJDT, so I don't know what the proper behavior in your situation should have been.
(In reply to comment #10) > OK. The build is available. The way it is with this new build, you will > receive a warning if the hook line is not in the config file, but the weaving > bundle will still be activated. Note that both are required in order for the > weaving service to be enabled. and it works like a charm now. Thanks a lot for such a quick solution. > When Equinox Aspects is installed through p2, the hook line will be added to > the config.ini in the proper way. However, I don't know how you installed > AJDT, so I don't know what the proper behavior in your situation should have > been. I use the p2 Agent to install/update bundles into different profiles. That's all done as a privileged user, so the agent will have full access to the shared locations.At runtime users only have read-access to the profile locations and the bundle pool.
Great. So, this seems like a reasonable solution for you. The problem was that JDT Weaving was forcing the re-write of the config.ini when it should not have. We are now more careful not to do that. In the future, I can consider also looking at local config.ini files to see if the hook line exists, but since the hook line will exist whenever p2 is used (and almost everyone uses p2 now), I'd consider this a very low priority.
