December 2009 - jboss-osgi-dev - Jboss List Archives

[JBoss OSGi Development] - MC related issue backlog

by thomas.diesler＠jboss.com

Folks, I started a page that tracks dependencies on changes in the various MC modules http://spreadsheets.google.com/pub?key=tClESgsML8JRimweajU-3oQ >From a practical perspective it is probably not enough to have these issues create in JBOSGI and hope that they get fixed somehow in MC. Instead, I suggest we create dependent issues in the respective MC modules and assign a living soul to each of them to make the next progress step. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270169#4270169 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270169

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Incompatible framework dependencies

by thomas.diesler＠jboss.com

The framework/trunk location is now active View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268972#4268972 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268972

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Incompatible framework dependencies

by thomas.diesler＠jboss.com

I'm ready for the Beta5 release, which will hopefully be tagged today. anonymous wrote : | As a consequence, I suggest to move framework to its natural location again (i.e. projects/runtime/framework/trunk) since its life as reactor project has ended. | Please use | svn switch https://svn.jboss.org/repos/jbossas/projects/jboss-osgi/projects/runtime/... | after the Beta5 announcement. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268969#4268969 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268969

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Service mix part deux (II.)

by alesj

Initial service mixture test: * http://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/trunk/reactor/... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268587#4268587 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268587

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Unexpected dependee state changes

by thomas.diesler＠jboss.com

I think the difference is between implicit and explicit re-wiring of the bundle graph. The OSGi spec chooses the explicit approach where you have to explicitly use PackageAdmin or restart the framework to cause a rewiring. An implicit approach would mean that on every bundle update/uninstall the framework would bounce every bundle that depends on the uninstalled bundle causing a potential change in behaviour (because they wire to something else) Anyway, this is how the spec defines the classloading sematics of uninstalled bundles. Stale services can be avoided by using ServiceTracker i.e. you should never hold on to a service that is not being tracked. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268466#4268466 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268466

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Unexpected dependee state changes

by alesj

"thomas.diesler(a)jboss.com" wrote : | I realize that this behaviour may not be natural to MC, but it is how OSGi works AFAIU. | | After uninstall of X, B should still be able to load classes from X. ServiceTracker should be used to act upon the unregistered services from X, but this would apply to bundleX.stop() as well. | Both of these seem very un-natural to me. * class leakage? * stale services usage * ... Is there a valid reason to allow this? Does it say when the PackageAdmin::refresh needs to be invoked? (btw: why is PA even mentioned wrt core framework? shouldn't core be "self-enough") View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268462#4268462 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268462

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Unexpected dependee state changes

by thomas.diesler＠jboss.com

Bundle B may also use a BundleTracker to catch and react upon the state change of bundle X. This however would create a tight coupling between B and X, which you generally would like to avoid. After uninstall of X, B should still be able to load classes from X. ServiceTracker should be used to act upon the unregistered services from X, but this would apply to bundleX.stop() as well. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268431#4268431 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268431

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Unexpected dependee state changes

by thomas.diesler＠jboss.com

It's not quite ok AFAIK | If this bundle has exported any packages, the Framework must continue to make these packages available to their importing bundles until the PackageAdmin.refreshPackages method has been called or the Framework is relaunched. | Hence, from the class loading perspective bundle B should continue to work. From the service perspective, bundle B may track services that are provided by X and may unregister its own services. However, that behaviour would depend on the nature of those services. Generally, it is not ok that BundleActivator.stop() is called on bundle B (causing all of its services to get unregistered) only because one of the bundles it imports packages from gets uninstalled. I realize that this behaviour may not be natural to MC, but it is how OSGi works AFAIU. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268428#4268428 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268428

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Unexpected dependee state changes

by alesj

Isn't it OK that B was un-winded, as its dependency X was uninstalled? e.g. it cannot be active, if it's missing X's packages View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268301#4268301 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268301

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Unexpected dependee state changes

by thomas.diesler＠jboss.com

anonymous wrote : | Once this method returns, the state of the OSGi Service Platform must be the same as if the bundle had never been installed, unless: | | * The uninstalled bundle has exported any packages (via its Export-Package manifest header) | * The uninstalled bundle was selected by the Framework as the exporter of these packages. | | If none of the old exports are used, then the old exports must be removed. Otherwise, all old exports must remain available for existing bundles and future resolves until the refreshPackages method is called or the Framework is restarted. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268283#4268283 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268283

15 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-dev December 2009