Community
Participate
Working Groups
When we add the reconciler bundle to a p2 provisioned SDK, we are suddenly not prompted for the workspace location on startup. - provision an SDK - start the SDK - note that you get the workspace launcher - exit SDK - add the reconciler bundles as described by: http://wiki.eclipse.org/Equinox_p2_tests#Update_Manager_compatibility - start the SDK - the workspace will automatically start up, and the workspace location will default to (on windows) c:/documents and settings/<user>/workspace In the reconciler bundle we start a bunch of bundles, including the core.runtime bundle. I *think* this may coincide with when the workspace launcher stopped appearing. The reason we added the runtime bundle was to work around the problems described by bug 216478 comment 14.
I'd like to work on getting the reconciler integrated today so I'm keen to understand this.
fyi I removed the startup call to core.runtime and again received the problems with the keyring. Caused by: java.lang.IllegalStateException: The keyring file location has already been specified D:\temp\zzz\user\configuration\org.eclipse.core.runtime\.keyring. at org.eclipse.core.internal.runtime.auth.AuthorizationHandler.setKeyringFile(AuthorizationHandler.java:215) at org.eclipse.core.internal.runtime.InternalPlatform.initializeAuthorizationHandler(InternalPlatform.java:602) at org.eclipse.core.internal.runtime.InternalPlatform.start(InternalPlatform.java:743) at org.eclipse.core.internal.runtime.PlatformActivator.start(PlatformActivator.java:31) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993)
Unfortunately I don't have any great insight about this. ECF now has an optional dependency on org.eclipse.core.net for the proxy handling (bug 216478). We also added dependencies on the JRE classes (in CDC 1.0/Foundation 1.0): import java.net.Authenticator; import java.net.PasswordAuthentication; I suppose it's possible that referring to these classes is resulting in loading of auth.compatibility and/or core.runtime (?)...but it doesn't seem likely to me. I don't know enough about the auth.compatibility bundle to know. Is it possible that the core.net bundle is loading core.runtime/auth.compatibility...even after the recent patches submitted by DJ? Sorry I can't be more immediately helpful.
Yeah, the new core.net code does reference the auth code. That patch I gave them was a whole 3 weeks ago so that's why i forgot. :) (just checked) The code was using the Platform class and it was changed to use the internal class. So basically I am causing my own problems and then forgetting that I did it. Wonderful.
On a side note, does the addition of the start of the core.runtime bundle explain the missing workspace launcher?
It is also a little alarming that we are so sensitive to the bundle startup order w.r.t. the auth bundle.
The symptom you are seeing means a bundle accessed the instance location before the IDE application had a chance to open a prompt to ask about it. The most common cause of this is that something caused org.eclipse.core.resources to be started, which accesses the instance location. Since no location has been set, the default location is used. I didn't think that a reference to org.eclipse.core.runtime would cause this - I thought we were careful not to require the instance location during runtime startup.
John, I agree... there must be something else going on here. I have entered bug 218058 to address the startup problems with the runtime and auth bundles.
This problem has always been. The instance location is set to a default value whenever someone is asking for it and it has not been set to a real value. Here, by changing the startup sequence we just created a code path that cause the value to be obtained...
In the activator for the core.net bundle, it eventually tries to access the instance preferences which causes the workspace location to be set to the default value. So this is what is happening... - if you start a regular SDK then everything is ok - we add the reconciler bundle - when we start, we use ECF - ECF uses core.net - core.net looks in the instance preferences - but this is all before the instance location has been set - the preferences code then sets the location to be the default - then the ide.application comes along and the location has already been set so it doesn't prompt the user I *think* the solution is for core.net to check and see if the instance location has been set before trying to access the preferences because you should be able to use that bundle without an instance location. Any other comments?
Your explanation and proposed solution make sense to me...
Created attachment 89086 [details] initial patch Here's an initial patch following DJs idea. Basically we always verify that the everything is initialized before calls on the ProxyManager are allowed to proceed. In this patch if the check fails we throw an IllegalStateException. We might soften that but its a start. I tried this quickly in a basic Eclipse startup but haven't exercised in the context of the resolver yet.
A good start but I don't think we can throw this unchecked exception if the instance location isn't set... that might break too many people since the old code path would essentially try to do the work but in a default location. We should talk to Tomasz and Michael about this tomorrow... essentially all we want to do is protect against accessing the preferences before they become available. Some of the other actions (like registering the authenticator) can still be performed.
Can you give a stack trace of how this is happening on startup? Stepping back a bit, use of ECF suggests the possibility of network activity, which is not something we ever want to happen during startup.
You forget that now every access to content.xml/jar and artifacts.xml/jar is done through ECF even when the file is local. Therefore ECF != remote.
I believe it was with the initialization of the profiles/metadata repositories. I don't have a stack trace handy but can try and reproduce one later.
Ok, the stack would be interesting. Even loading of local repositories shouldn't be strictly necessary until actually performing provisioning operations.
Created attachment 89175 [details] stack Ok, here is a stack trace.
(In reply to comment #18) > Created an attachment (id=89175) [details] > stack > > Ok, here is a stack trace. > This makes me regret actually addressing bug 181544...as the optional use of core.net has apparently opened a can of worms. Sorry about that (DJ and all). I had no idea about core.net. If it becomes/is critical, I could remove this ECF code that accesses the core.net proxy API and the optional dependency and we could deal with the core.net dependency issues later. Just LMK.
Scott, don't worry about it. This was a problem waiting to happen in core.net, it was just a matter of time before someone touched it too early in the startup sequence. We've hit this before with other plugins, and it will give us an opportunity to make core.net more robust.
Created attachment 89314 [details] proposed patch Talking with Mike he suggested that moving the proxy settings from instance scope to configuration scope would be fine. This is beneficial as it would allow us to use core.net proxy support in situations where there is no instance area defined. This does however require us to the backwards compatability work to migrate settings from the instance scope (when/if available) to the configuration scope. This patch moves the proxy settings to the configuration scope and migrates the settings from the instance scope. We previously had migrated settings from "update" and I have not removed this code and left it as the first step of instance scope setting migration. To allow an instance location to be set "after" initializing the ProxyManager we call "checkMigrated" before each public method. I am not a committer on the team components so this will have to be reviewed and committed by someone else once its in final shape. DJ could you take a look at this patch.
Moving to Platform Team for consideration.
I have a couple of issues with the patch: 1) The fact that a migration has occurred is only registered in an instance variable. While there are some null checks in the migration code, it still looks like it may be possible that old settings from the instance scope that were removed from the configuration scope by user action could be re-migrated. I would rather see a flag that is set in the preferences that indicate that the migration has already taken place. That way we would be sure that settings would not be migrated more than once. 2) If the settings are placed in the configuration scope, then they will be lost when the user upgrades to a newer version of Eclipse via downloading (as opposed to updating). We had similar issues with the keyring file. The main difference is that an alternate location can be specified for the keyring file. It would be good if we had some way for users to keep their proxy settings across a re-install. This would be less of an issue if we had the ability to use the system settings.
(In reply to comment #23) > It still > looks like it may be possible that old settings from the instance scope that > were removed from the configuration scope by user action could be re-migrated. > I would rather see a flag that is set in the preferences that indicate that the > migration has already taken place. That way we would be sure that settings > would not be migrated more than once. That sounds fine. Would you prefer to see the marker in the instance or configuration scope as there seems to be a trade-off. 1) If it's in config scope this will prevent importing settings from other workspaces 2) If it's in instance scope this will prevent other instances of eclipse from importing these settings. I'm leaning towards (1) for limiting the automatic upgade, but allowing the "import" to add settings if they're not present. > 2) If the settings are placed in the configuration scope, then they will be > lost when the user upgrades to a newer version of Eclipse via downloading (as > opposed to updating). We had similar issues with the keyring file. The main > difference is that an alternate location can be specified for the keyring file. > It would be good if we had some way for users to keep their proxy settings > across a re-install. This would be less of an issue if we had the ability to > use the system settings. Hmm... we probably don't want to introduce anything too fancy here. Off the top of my head I wonder if we can get away with what we have currently e.g "Import --> Preferences".
Created attachment 90103 [details] proposed patch v2 This patch adds the check for migration flag in the config scope. If the user does an explicit Preference import the migration flag is not checked so will still allowing the addition of proxies.
Patch released
Verified.
