[equinox-dev] [prov] Strange error message: org.osgi.framework.BundleException: State change in progress for bundle ...
I started to refactor SimpleArtifactRepositoryFactory to use ECFTransport instead of using URL.openStream() to load the artifacts.xml. In my first attempt I was using ECFTransport to download artifact.xml into a temporary file and than reading its content with SimpleArtifactRepositoryIO. This worked very well (I used ProvAdminUI for testing) but I didn´t like the temporary file storage. My second attempt was to use a PipedInput/Ouputstream pair to do that. Therfore I start a download thread which uses ECFTransport pushing into the PipedOutputStream and the linked PipedInputStream is read by SimpleArtifactRepositoryIO. When I now start ProvAdminUI I got the following error message: !ENTRY org.eclipse.osgi 2 0 2007-12-17 08:32:25.687 !MESSAGE While loading class org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport$1, thread Thread[Thread-2,6,main] timed out waiting (5000ms) for thread Thread[main,6,main] to finish starting bundle [EMAIL PROTECTED]:file:../../projekte/rcp/org.eclipse.equinox.p2.artifact.repository/ [17]. To avoid deadlock, thread Thread[Thread-2,6,main] is proceeding but org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport$1 may not be fully initialized. !STACK 0 org.osgi.framework.BundleException: State change in progress for bundle [EMAIL PROTECTED]:file:../../projekte/rcp/org.eclipse.equinox.p2.artifact.repository/ by thread main. at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1139) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:259) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:419) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:344) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:412) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:373) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:361) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport.transfer(ECFTransport.java:72) at org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport.download(ECFTransport.java:67) at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepositoryFactory$Transporter.run(SimpleArtifactRepositoryFactory.java:68) Caused by: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException ... 16 more Root exception: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1139) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:259) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:419) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:344) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:412) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:373) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:361) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport.transfer(ECFTransport.java:72) at org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport.download(ECFTransport.java:67) at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepositoryFactory$Transporter.run(SimpleArtifactRepositoryFactory.java:68) It seems that is not possible to load the ECF class IFileTransferListener within a thread (this happens at ECFTransport.java:72). The Activator of o.e.e.p2.artifact.repository creates the
Re: [equinox-dev] [prov] Strange error message: org.osgi.framework.BundleException: State change in progress for bundle ...
It seems that there is a difference between loading a class (from another bundle) from the ´main´ thread and from a spawned thread while activating a bundle. There is no difference between loading a class from the main thread or from another thread. All calls end up in the same place. What you are experiencing here is a deadlock while loading classes, however because equinox is so cool, it is telling you so with the following message: To avoid deadlock, thread Thread[Thread-2,6,main] is proceeding but org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport$1 may not be fully initialized. This happens because while the bundle is being activated (and has not finished its activation, the call from Activator.start() has not returned), another thread is trying to load a class from it. However since the contract of our classloaders is to fully activate the bundle this class loading request can not be done. This kind of problem is usually encountered when activators are doing too much work. A good practice for activators is to do as little as possible. Now for this particular problem with the artifact repository manager, the problem stems from the eager loading of the repository content. Instead, on restart the repository manager should only load the URLs of the repository and then only load the content on request. This approach has already been implemented in the metadata repo manager but has not been put to use for the artifact repo manager. It may worth experiencing with this. HTH PaScaL From: Stefan Liebig [EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 12/17/2007 03:26 AM Subject:[equinox-dev] [prov] Strange error message: org.osgi.framework.BundleException: State change in progress for bundle ... I started to refactor SimpleArtifactRepositoryFactory to use ECFTransport instead of using URL.openStream() to load the artifacts.xml. In my first attempt I was using ECFTransport to download artifact.xml into a temporary file and than reading its content with SimpleArtifactRepositoryIO. This worked very well (I used ProvAdminUI for testing) but I didn´t like the temporary file storage. My second attempt was to use a PipedInput/Ouputstream pair to do that. Therfore I start a download thread which uses ECFTransport pushing into the PipedOutputStream and the linked PipedInputStream is read by SimpleArtifactRepositoryIO. When I now start ProvAdminUI I got the following error message: !ENTRY org.eclipse.osgi 2 0 2007-12-17 08:32:25.687 !MESSAGE While loading class org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport$1, thread Thread[Thread-2,6,main] timed out waiting (5000ms) for thread Thread[main,6,main] to finish starting bundle [EMAIL PROTECTED]: file:../../projekte/rcp/org.eclipse.equinox.p2.artifact.repository/ [17]. To avoid deadlock, thread Thread[Thread-2,6,main] is proceeding but org.eclipse.equinox.internal.p2.artifact.repository.ECFTransport$1 may not be fully initialized. !STACK 0 org.osgi.framework.BundleException: State change in progress for bundle [EMAIL PROTECTED]: file:../../projekte/rcp/org.eclipse.equinox.p2.artifact.repository/ by thread main. at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1139) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:259) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:419) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:344) at
Re: [equinox-dev] Declarative Services with RCP Plug-in Extensions
Thanks for your help Thomas, your clue about our config.ini not requiring all of those bundle-startups led me on the path to the solution. It turns out that we were using the OSGi launcher and not the Equinox/Eclipse launcher and that's why we needed to explicitly start all of those bundles in order to start our RCP Application. Now that we're using org.eclipse.equinox.launcher, the Application is shutting down just fine and our configurations are much cleaner. Only now that I looking back at your email again, do I see that you mention that we should be using org.eclipse.equinox.launcher. Which DS implementation are you using? The latest version of DS on the Equinox download page should fix the thread safety issues. The l atest DS implementation is provided by Prosyst and has many improvements over our old Equinox implementation of DS. Is it best to use the latest 1.0.0 version, or the latest 0.1.0 version? Thanks again, - Darren Thomas Watson [EMAIL PROTECTED] 11/28/07 11:20 AM [EMAIL PROTECTED] wrote on 11/27/2007 06:19:11 PM: Hello. I need some tips in narrowing down the cause of a problem We've been having in our RCP/OSGi application. Our project is using Declarative Services to manage several bundles of services, and Eclipse Plug-in Extensions for various RCP components. Everything seems to be running ok, but I'm having trouble with one thing: getting the OSGi framework and all of the bundles to shut down when the user closes the RCP Application window. First, a few questions: - I read articles like http://www.eclipsezone.com/articles/extensions- vs-services/ and start to worry if our use of both DS and RCP plug- ins is somehow fundamentally problematic. There is a lot of functional overlap, but do these two approaches ever conflict? Is there a standard way to get them to work together to close down when the application is done? Is it remotely possible that the org.eclipse.equinox.ds resolver's ConcurrentModificationException during the startup of an OSGi framework could have anything to do with preventing the entire OSGi framework from shutting down automatically after the RCP Applicationis closed? Which DS implementation are you using? The latest version of DS on the Equinox download page should fix the thread safety issues. The latest DS implementation is provided by Prosyst and has many improvements over our old Equinox implementation of DS. Eclipse automatically seems to understand that we want the framework to shut down when the application closes, but when we take our jars out into the real world, the framework doesn't stop. I suppose this is understandable, since we tell OSGi to start the applications and to start the bundles and services. How do we tell OSGi that they are linked, and must be shut down when the Application closes? By default the framework should be shutdown by EclipseStarter once your application has ended. This should cause all your bundles to be stopped automatically. I suspect you are having issues with non-daemon threads still being active. When shutting down we never call System.exit, we assume that all non-daemon threads will be stopped by the shutdown process. This is what Alex was describing in his response. If you use the launcher org.eclipse.equinox.launcher it does actually exit with System.exit as long as you don't use -noexit option. See the quick start guide for instructions on using the launcher. http://www.eclipse.org/equinox/documents/quickstart.php About our configuration: -- The framework is started up with the following command: java -cp . -jar org.eclipse.osgi_3.3.0.v20070530.jar -console config.ini is as follows -- eclipse.ignoreApp=false osgi.noShutdown=false osgi.bundles= \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED], \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ org.eclipse.swt.win32.win32.x86, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [All of our bundles follow at run level 4] You should not have to start every bundle here. You should only have to start equinox.common, core.runtime and update.configurator and any bundles which need to be activated because they publish OSGi services (this includes DS, event, log etc.). Something like this should work:
Re: [equinox-dev] [prov] Comments on wiki Equinox p2 Shared Install Plan
If I was looking at this from the perspective of only RPM for the SDK, you would likely be close enough. bundles.txt stored in user home. YES. I would change that to stored in users workspace or preferable user's configuration space. Yes, configuration space is more accurate. I just meant the user's writable location (I'm thinking something like ~/.eclipse/p2). That is ok as a default maybe. However this decision should be deferred until runtime. A user might want to run multiple instances with multiple configurations. If bundles.txt is missing from the user's workspace then it needs to be populated with the shared bundles.txt. Why can't it just run from the shared bundles.txt? Ahh. That was a bad paraphrase of what I thought you indicated. So if you load the shared bundles.txt how do you get a user's bundle.txt? How long do you use the shared? If you want to populate the user's bundle.txt with sdk in shared install then in can be driven as a root IU or profile. However this is a policy decision and should not be hard-wired as always happening. I don't know what you mean here. One size does not fit all. One user might want bundle A from ABC and another user might want bundle A from XYZ. The admin might want to provision a limited functionality product for user A. And he might want to provision prototype stuff for user B. This can all be driven through the profiles/IUs. The act of provisioning the bundles also allows for the unfolding/customizing of additional artifacts related to specific bundles. An example of additional work would be creating user ICONs, setting environmental variables. What we are really talking about is running only a configuration phase to get the user's bundle.txt up to the latest. The phases collect, and install are not wanted. This is not ideal for the Linux distribution case. We want things to be completely ready to go after the user installs the packages. .desktop files and other metadata is just shipped in the package and put in the right place upon installation so there's no need for additional configuration in this case. It is nice that you can still do that. That is far from ideal for us. We have to be able to maintain our products in many ways, rpm being just one. For instance the admin wants to upgrade a few bundles in the shared install. One of the bundles may need the libpath modified to point to the new native dll. If a bundle and IU can manage itself it is a lot easier. We also have to support many platforms besides RedHat. By containing/managing bundle artifacts on a bundle basis we are much more efficient. Only the bundle developer needs to work on the change. If the user is running multiple workspaces where one workspace uses jdk A and one uses jdk B. It will be hard to manage the property differences in an rpm. Are you saying that an admin will only upgrade the shared install through rpm and the update UI can not be used? Materialize profile from running bundles.txt I am suggesting it is better to materialize bundles.txt from the profile. It's difficult and fragile to do profile manipulation with headless package installation. I'm specifically talking about the installation of additional bundles here: CDT, Mylyn, etc. Pascal mentioned that he has some in-progress code that will allow the materialization of bundles.txt from the running instance and a set of root IUs. I am not sure why it should be harder. One way or another we have to have a profile/profile(s) that represents the configuration that the user will run with. So after CDT is installed it seems that we would still need profiles and rootIUs that represent the installation or we will not be able to make decisions about updates. If we start driving from both ends it has to be harder. Andrew Overholt [EMAIL PROTECTED] com To Sent by: Equinox development mailing list equinox-dev-bounc equinox-dev@eclipse.org [EMAIL PROTECTED] cc Subject 12/17/2007 12:00 Re: [equinox-dev] [prov] Comments PMon wiki Equinox p2 Shared Install Plan Please respond to Equinox development mailing list
[equinox-dev] Equinox tagged for 3.4 I-Build
The map file has been updated for the following Bug changes: + Bug 211745. [sec] Graduate signedcontent API and related services (ASSIGNED) + Bug 211904. [launcher] Running from outside current directory causes contents of .ini file to be ignored (FIXED) The following projects have changed: org.eclipse.equinox.executable org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] Comments on wiki Equinox p2 Shared Install Plan
Hey James, this is alot of good information. Would you have a chance to update the shared install scenarios document to highlight some of the points? My gut feeling from reading your comments is that most of what you suggest is do-able wrt the underlying infrastructure but the current context is driving Andrew et al to express things in a different way (that may or may not line up with your situations). Andrew, can you point James to the best place to capture the scenario information and integrate it with the other doc you have? Jeff James D Miles [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 12/17/2007 02:44 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] [prov] Comments on wiki Equinox p2 SharedInstall Plan If I was looking at this from the perspective of only RPM for the SDK, you would likely be close enough. bundles.txt stored in user home. YES. I would change that to stored in users workspace or preferable user's configuration space. Yes, configuration space is more accurate. I just meant the user's writable location (I'm thinking something like ~/.eclipse/p2). That is ok as a default maybe. However this decision should be deferred until runtime. A user might want to run multiple instances with multiple configurations. If bundles.txt is missing from the user's workspace then it needs to be populated with the shared bundles.txt. Why can't it just run from the shared bundles.txt? Ahh. That was a bad paraphrase of what I thought you indicated. So if you load the shared bundles.txt how do you get a user's bundle.txt? How long do you use the shared? If you want to populate the user's bundle.txt with sdk in shared install then in can be driven as a root IU or profile. However this is a policy decision and should not be hard-wired as always happening. I don't know what you mean here. One size does not fit all. One user might want bundle A from ABC and another user might want bundle A from XYZ. The admin might want to provision a limited functionality product for user A. And he might want to provision prototype stuff for user B. This can all be driven through the profiles/IUs. The act of provisioning the bundles also allows for the unfolding/customizing of additional artifacts related to specific bundles. An example of additional work would be creating user ICONs, setting environmental variables. What we are really talking about is running only a configuration phase to get the user's bundle.txt up to the latest. The phases collect, and install are not wanted. This is not ideal for the Linux distribution case. We want things to be completely ready to go after the user installs the packages. .desktop files and other metadata is just shipped in the package and put in the right place upon installation so there's no need for additional configuration in this case. It is nice that you can still do that. That is far from ideal for us. We have to be able to maintain our products in many ways, rpm being just one. For instance the admin wants to upgrade a few bundles in the shared install. One of the bundles may need the libpath modified to point to the new native dll. If a bundle and IU can manage itself it is a lot easier. We also have to support many platforms besides RedHat. By containing/managing bundle artifacts on a bundle basis we are much more efficient. Only the bundle developer needs to work on the change. If the user is running multiple workspaces where one workspace uses jdk A and one uses jdk B. It will be hard to manage the property differences in an rpm. Are you saying that an admin will only upgrade the shared install through rpm and the update UI can not be used? Materialize profile from running bundles.txt I am suggesting it is better to materialize bundles.txt from the profile. It's difficult and fragile to do profile manipulation with headless package installation. I'm specifically talking about the installation of additional bundles here: CDT, Mylyn, etc. Pascal mentioned that he has some in-progress code that will allow the materialization of bundles.txt from the running instance and a set of root IUs. I am not sure why it should be harder. One way or another we have to have a profile/profile(s) that represents the configuration that the user will run with. So after CDT is installed it seems that we would still need profiles and rootIUs that represent the installation or we will not be able to make decisions about updates. If we start driving from both ends it has to be harder. Andrew Overholt [EMAIL PROTECTED] Andrew Overholt [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 12/17/2007 12:00 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] [prov]
