Initially they are started with bundle.start(). Then my application is stopped. 
 
Now again when it is started the state is maintained  from the OSGi cache after 
which my module loader does a bundle.update(), which in turn I guess again does 
a stop() and start(). Should the initial start be start(START_TRANSIENT) ? what 
is it's significance ..? 

Thanks, 
Srijith. 


>>> Alex Blewitt <[email protected]> 4/27/2010 1:02 PM >>>

Were they started with bundle.start() or bundle.start(START_TRANSIENT)?

Sent from my (new) iPhone 


On 27 Apr 2010, at 08:02, "Srijith Kochunni" <[email protected]> wrote:





Thanks for the explanation Tim. I understand the refresh phenomenon now. 
>>  

If the bundle was started before the refresh operation, it will automatically 
be restarted after it has been rewired. 

  
 However this I don't see happening. Not sure why.. The Bundle just remains in 
RESOLVED state. If I manually start it, it starts fine. 


Thanks, 
Srijith. 



>>> "Tim Diekmann" <[email protected]> 4/27/2010 11:35 AM >>>

The refresh operation rewires the bundles that need to be rewired based on the 
changes your agent made to the bundle wiring state. In order to rewire a bundle 
it has to be stopped and a new classloader is created for the bundle. If the 
bundle was started before the refresh operation, it will automatically be 
restarted after it has been rewired. 



BTW, wiring is the term for the import and export package relationship between 
bundles. The framework creates a link (wire) between the bundles based on their 
metadata in manifest.mf. 



Does this help explaining the refresh phenomenon?

 Tim. 




On Apr 26, 2010, at 22:36, "Srijith Kochunni" <[email protected]> wrote:






Are you suggesting that when I invoke refreshPackages, I must do it in a 
separate thread.?  Either way why would this call stop an active bundle ? Don't 
quite get that. 


Thanks, 
Srijith. 


>>> "Tim Diekmann" <[email protected]> 4/27/2010 10:45 AM >>>

The refreshPackages() is required to perform it's operation in a separate 
thread according to the spec. This makes it use tricky and hardly predictable.

 Tim. 




On Apr 26, 2010, at 22:09, "Srijith Kochunni" <[email protected]> wrote:






Hi 


          I have an equinox runtime, where I have deployed my bundles. I notice 
that at times, when I do not do a clean start, as in start without osgi.clean 
option, I notice that some of my bundles go into Stopped state. This happens 
when a "Refresh packages"  thread spawned by the framework is run. It seems to 
be stopping my application bundles.  


           My setup is such that I am using my own custom module loader, which 
loads my bundles from a pre-specified folder and after my bundles are installed 
/ updated, I also directly invoke PackageAdmin.refreshPackages and it seems to 
be returning correctly and all bundles are in a proper state, but then this 
thread gets spawned and it seems to stop most of my application bundles. Not 
sure what the problem is, so I did a dump of my stack Trace in my Activator 
stop and I could see this  


        at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl$3.run(BundleContextImpl.java:1050)
 
        at java.security.AccessController.doPrivileged(Native Method) 
        at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:1046)
 
        at 
org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:457)
 
        at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:531)
 
        at 
org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1104)
 
        at 
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:280)
 
        at 
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:415)
 
        at 
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:223)
 
        at 
org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:162)
 
        at java.lang.Thread.run(Unknown Source) 


 Wanted to know when this would happen / how it can be rectified. Also wanted 
to know, whether it is possible to stop the Refresh packages thread from being 
spawned through some configuration, because I am anyway invoking it directly in 
my application and therefore don't need the framework to do it. Any help 
regarding this would be much appreciated. 


 Thanks, 
 Srijith. 
 


_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 


_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 


_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Reply via email to