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
