Re: [equinox-dev] Regarding PackageAdmin refreshPackages.

[Alex Blewitt <alex.blewitt@xxxxxxxxx>]

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" <ksrijith@xxxxxxxxxx> 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" <tdiekman@xxxxxxxxx> 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" <ksrijith@xxxxxxxxxx> 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" <tdiekman@xxxxxxxxx> 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" <ksrijith@xxxxxxxxxx> 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
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev