org.osgi.framework.BundleException: State change in progress for bundle

Have you every come across this kind of issue with your eclipse plugin start () ???

!MESSAGE While loading class "org.scribe.model.Verb", thread "Thread[ModalContext,6,main]" timed out waiting (5000ms) for thread "Thread[main,6,main]" to finish starting bundle "com.xx_3.0.0.qualifier [812]". To avoid deadlock, thread "Thread[ModalContext,6,main]" is proceeding but "org.scribe.model.Verb" may not be fully initialized.
!STACK 0
org.osgi.framework.BundleException: State change in progress for bundle "reference:file:/D:/Work/KKIDE/devtools/trunk/guieditor/" by thread "main".
at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1077)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:282)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:417)
at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:265)
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:453)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:469)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.scribe.builder.api.DefaultApi10a.getRequestTokenVerb(DefaultApi10a.java:103)
at org.scribe.oauth.OAuth10aServiceImpl.getRequestToken(OAuth10aServiceImpl.java:50)
at org.scribe.oauth.OAuth10aServiceImpl.getRequestToken(OAuth10aServiceImpl.java:39)
at org.scribe.oauth.OAuth10aServiceImpl.getRequestToken(OAuth10aServiceImpl.java:44)
at ..
at ..
org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Caused by: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException
... 22 more




Will try to understand the issue first, by looking at the statement below.
While loading class "org.scribe.model.Verb", thread "Thread[ModalContext,6,main]" timed out waiting (5000ms) for thread "Thread[main,6,main]" to finish starting bundle "com.xx_3.0.0.qualifier [812]". To avoid deadlock, thread "Thread[ModalContext,6,main]" is proceeding but "org.scribe.model.Verb" may not be fully initialized.


This indicates that one thread is attempting to load from the org.scribe.model. bundle while another thread is in the process of activating it.  On the Sun VM a deadlock can occur because the VM locks the classloader way too early.  I'm guessing that you are calling Display.asyncExec()/Display.syncExec in your bundle activation code.  What can happen in this case is you post a Runnable for SWT to run on the main UI dispatch thread.  Then the dispatch thread wakes up and decides to execute your runnable, this causes the UI thread to attempt to load more classes from your bundle (on the Sun VM the classloader is locked here) but the thread blocks because another thread is currently activating the bundle.  Meanwhile the thread which is activating the bundle continues to run more code which causes more classes to be loaded from your bundle, unfortunately the UI thread has a lock on the bundle classloader (now we are deadlocked).
In Equinox it detects this situation and break out of the deadlock after 5 seconds(5000ms).

One way to avoid the situation is to put all your async posts at the very end of your activation code so that you exit very quickly without loading additional classes.

It better to use aysnc execution, since bundle activation thread will return immediate and will go to active state, otherwise bundle activation thread will be blocked until your service gets over. But anyway this will vary based on call what we wanted to do it in start method.