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
