Community
Participate
Working Groups
We are currently experiencing an issue that is outlined below: - ECF depends on core.net - core.net depends on runtime.compatibility.auth - application starts - ECF does something which calls code in the auth bundle to set the keyring - later someone else has a dependency on the core.runtime bundle - the runtime bundle depends on the auth bundle - the runtime bundle tries to start - application exits because there is an error 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) So is it possible for someone to use the auth bundle and then later someone else use runtime? Perhaps the auth bundle is meant for use by the runtime bundle only since there is no real API? Note that currently the core.net bundle references internal classes. Is there an alternate way for the core.net bundle to use the services provided by the auth bundle without going through the runtime bundle and Platform class? Oleg, do you have thoughts or ideas on this?
We've talked about this and decided the best course of action is for the core.net bundle to re-introduce their dependency on the core.runtime bundle. Then post-M5 they can move to the new security APIs once they graduate from the incubator. The original urgency of getting core.net to move off the core.runtime APIs is not as urgent now that ECF has been fixed so its dependency on core.net really is optional. The bug against core.net is bug 214796.
Re-opening to close. :)
The core.net bundle has reverted its code so it now requires the core.runtime bundle. We have removed the code in the reconciler activator which manually started the core.runtime bundle to work around this problem.
