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

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

by alesj

Starting a new fresh thread, as the old one is pretty much tangled up with a bunch of useless tracking-impl info. * http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160504 OK, I have cleaned up OSGi MC Facade to work directly off ContextTracker and ContextQueries: * OSGiManager registeredServices --> controller/context queries * AbstractBundleState servicesInUse --> context tracker getUsedContexts * OSGiServiceState usedBundles --> context tracker getUsers(this) I currently just imitated previous behavior, explicitly using just OSGi notions - no non-OSGi+MC context usage yet. So my question is: (a) how do we handle non-OSGi context in OSGi Facade (b) how do we handle OSGi services with additional properties in non-OSGi I guess (b) should be simple. e.g. as we already discussed, put service's properties into MDR/Instance and allow for context filtering based on those properties. But otherwise the plain usage should be type matching, on exposed service's classes. What about (a)? What is MC POJO's bundle? I guess this is why every deployment has OSGiBundleState, which is what we should return / use? And I guess this - JBDEPLOY-65 - is needed to make a mapping from context to deployment unit --> OSGiBundleState? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267566#4267566 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267566

15 years

1
0
0 / 0

[JBoss OSGi Development] - Re: Incompatible framework dependencies

by thomas.diesler＠jboss.com

It's really not such a big deal if you understand the difference between reactor and standalone project. If framework would have started in the reactor (as it should have) than this would be the first move. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267278#4267278 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267278

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Incompatible framework dependencies

by alesj

"thomas.diesler(a)jboss.com" 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. | Argh, not the moving again. I'm for it if Adrian also agrees, and you 110% promise you will never ever move it again. ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267264#4267264 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267264

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Incompatible framework dependencies

by thomas.diesler＠jboss.com

After a long discussion with Ales, we decided to cut the Beta5 release from a framework branch that uses compatible dependencies The location of that branch is as you might guess https://svn.jboss.org/repos/jbossas/projects/jboss-osgi/projects/runtime/... This effectively renders the reactor/framework stale with respect to the overall jbosgi/trunk build. Perhaps, at this point I should explain again what a "reactor project" is ... It is the home of fast moving jbosgi projects that want to participate in the overall jbosgi build and be part of the framework and container independent test matrix. Reactor projects are part of the installer and are QAed by the Hudson environment on different frameworks and target containers. Reactor projects cannot introduce dependencies that are not available in the supported target containers. Eventually, every reactor project will start its own lifecycle in jboss-osgi/projects when it becomes stable enough. Every project you see in jboss-osgi/projects (there are currently a little under 20 of them) has once started in the reactor and was an integral part of the jbosgi build. It seems that framework has crossed that bridge of introducing incompatible dependencies and needs to have a trunk version which is independent of the overall jbosgi build. A framework/trunk version also seems to be needed to make fast progress. The situation now is that framework still uses the reactor svn location, but is not part of the reactor build. 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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267255#4267255 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267255

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Incompatible framework dependencies

by alesj

"thomas.diesler(a)jboss.com" wrote : | these dependencies currently prevent the scheduled Beta5 release on 01-Dec-2009 | You shouldn't cut release from trunk, you should do it on a stable branch, which doesn't have such changes. I know we said we'll include service-mix into this release, but the changes are too big to be easily ported to AS in the last minute, hence it will have to wait for AS 6.0.M2. "thomas.diesler(a)jboss.com" wrote : | The downside of this is that the framework independent integration tests (i.e. examples, functional) are not available for trunk anymore, which was the original motivation to make framework a reactor project. | | If framework should stay a reactor project we cannot update the above mentioned dependencies in an uncoordinated way. Compatible updates are ok for as long as the enterprise examples run in all supported target containers. Either OSGi facade trunk needs a dedicated AS build / instance (or trunk directly), or those enterprise tests only make sense for stable branches. * http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266979#4266979 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267231#4267231 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267231

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Incompatible framework dependencies

by thomas.diesler＠jboss.com

Folks, these dependencies currently prevent the scheduled Beta5 release on 01-Dec-2009 | <version.jboss.classloading>2.0.8-SNAPSHOT</version.jboss.classloading> | <version.jboss.deployers>2.0.9-SNAPSHOT</version.jboss.deployers> | <version.jboss.kernel>2.2.0-SNAPSHOT</version.jboss.kernel> | We proabably need to rollback to the versions that are installed in jboss-6.0.0.M1 otherwise the JBoss OSGi release cannot happen. I realize that framework trunk needs to work with possibly newer SNAPSHOT versions than are installed in the supported target containers. As a consequence we probably need to decouple the MC Framework from JBoss OSGi and move it out of the reactor to projects/runtime/framework/trunk where it originally cam e from. The downside of this is that the framework independent integration tests (i.e. examples, functional) are not available for trunk anymore, which was the original motivation to make framework a reactor project. If framework should stay a reactor project we cannot update the above mentioned dependencies in an uncoordinated way. Compatible updates are ok however as long as the enterprise examples run in all supported target containers. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267205#4267205 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267205

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Remaining resolver issues

by thomas.diesler＠jboss.com

Folks, I have now removed the dependencies on the Resolver API and use PackageAdmin instead. Have a look at AbstractImportExportTest. There are currently three variations of this test case. * BasicResolver * RuleBasedResolver * NoExternalResolver The goal would be to remove all external resolver implementations and have none installed in the MC Framework. This however is currently not possible because of some non-trivial issues that are fixed by the Resolver approach. The most important one is covered by https://jira.jboss.org/jira/browse/JBOSGI-151 Consider | BundleC | exports A, B | imports A | | BundleD | exports A, | imports A, B | This only resolves when BundleC resolves using a self import for package A. If the MC resolver could actually reason over the full set of installed modules, the choice where it gets package A from would be arbitrary. Currently it however works such that it irrevocably uses the first match and cannot try another attempt if resolution is not sucessful. | Tests in error: | testCircularInstallDbeforeC(org.jboss.test.osgi.jbosgi151.OSGI151TestCase) | The following list defines the preferences, if multiple choices are possible, in order of decreasing priority: â¢ A resolved exporter must be preferred over an unresolved exporter. â¢ An exporter with a higher version is preferred over an exporter with a lower version. â¢ An exporter with a lower bundle ID is preferred over a bundle with a higher ID. There is test coverage for this, which also fails with NoExternalResolver. A related issue is this code in PackageAdminImpl | int resolved = 1; | while (resolved > 0) | { | resolved = 0; | Iterator<OSGiBundleState> it = resolvableBundles.iterator(); | while (it.hasNext()) | { | OSGiBundleState bundleState = it.next(); | if (bundleManager.resolveBundle(bundleState, false)) | { | it.remove(); | resolved++; | } | } | } | It iteratively tries to resolve the bundles through the MainDeployer by moving them to stage CLASSLOADER one by one. What's missing is an API that allows PackageAdmin to resolve the given bundles all at once. https://jira.jboss.org/jira/browse/JBDEPLOY-226 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267110#4267110 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267110

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by adrian＠jboss.org

NOTE: If you did decide to make the next MC release 3.0.x then that would exclude this feature getting backported into JBoss5 since it would be a major change in a stable branch there. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267043#4267043 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267043

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | MC-3.0.x would be the time when you can change the public api. | | | Not even for 2.2.x? Which is where I planned this. | (I have no intentions of providing this for 2.0.x). No. Major changes need an update to the major version number. See for example: http://java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/versioning2.htm... Of course, Java breaks its own rules. e.g. the changes to the java.sql interfaces between 1.5 and 1.6 - but then that's really between 5.x and 6.x in Sun's bizarre versioning of java. ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267042#4267042 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267042

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by alesj

"adrian(a)jboss.org" wrote : | MC-3.0.x would be the time when you can change the public api. | Not even for 2.2.x? Which is where I planned this. (I have no intentions of providing this for 2.0.x). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267040#4267040 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267040

15 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-dev November 2009