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

[JBoss OSGi Development] - Re: Define non OSGi bundle handling by the Framework

by adrian＠jboss.org

"thomas.diesler(a)jboss.com" wrote : To learn howto setup the hudson QA environment locally, have a look at | | http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapGettingStarted.html... How do I run this as a plain testsuite? Why aren't there regression tests for these features in reactor/framework? Each feature should have a unit test. Integration testing is a secondary test. If I can run the reactor/framework tests and it is 100% then all the supported features are working. Something without a unit test is NOT a supported feature. Adrian Brock's 1st Law of Programming. It it ain't tested it doesn't work. 1st Law Corollary It it ain't tested the feature doesn't exist. ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266323#4266323 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266323

15 years, 1 month

1
0
0 / 0

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

by alesj

"alesj" wrote : | Another problem/ugliness that I see is the usage of "external" service to do proper parameter type matching at uninstall. | OK, I think I know how to get past this one. But that still leaves the problem of actual service usage at undeploy: "alesj" wrote : | whereas service could still hold onto the ref - which might be an issue if that ref is ServiceFactory, | as ServiceFactory::unget could modify the actual created service. | Leave it to the expense of the user? :-) | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266233#4266233 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266233

15 years, 1 month

1
0
0 / 0

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

by alesj

"alesj" wrote : | But what to do with stop, destroy and uninstalls? | | | try { | | uninstallMethod.invoke(target, VMD::get) | | } finally { | | VDM::unget | | } | | | whereas service could still hold onto the ref - which might be an issue if that ref is ServiceFactory, | as ServiceFactory::unget could modify the actual created service. | Another problem/ugliness that I see is the usage of "external" service to do proper parameter type matching at uninstall. e.g. bean + parameters at uninstalls, bean + parameters in value-factory, ... This can be "properly" dealt with double call to ungetTarget. | if (unget) | { | try | { | Object target = context.getTarget(); | // do parameter type matching | ... | } | finally | { | context.ungetTarget(); | } | context.ungetTarget(); | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266147#4266147 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266147

15 years, 1 month

1
0
0 / 0

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

by alesj

Thomas, hold your horses. ;-) It will all be presented when some initial work is done. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266128#4266128 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266128

15 years, 1 month

1
0
0 / 0

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

by thomas.diesler＠jboss.com

"alesj" wrote : | * OSGi services will be exposed as MC beans | I suppose that means you can reference/inject OSGi services in the an MC descriptor. Could you describe/show how this would look like? How would this work with service properties. How would this work with multiple implementations of the same service interface? "alesj" wrote : | * MC beans will be listed as a OSGi services | I suppose that means you can reference/inject MC beans in a BP descriptor. Here as well, could you describe/show how this would look like? Do MC beans support service properties. Can you have multiple implementations of the same service interface? How would the service event model work i.e. Can I use ServiceTracker to track MC beans? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266126#4266126 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266126

15 years, 1 month

1
0
0 / 0

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

by alesj

"adrian(a)jboss.org" wrote : | In MC terms that is getTarget() for get. But we don't currently invoke an ungetTarget() at "uninjection" so that needs doing. This is tricker than it looks like, as we don't have just plain configuration injection. Ctor and properties injection have natural undeploy / uninjection. I could also somehow squeeze in create, start and installs. But what to do with stop, destroy and uninstalls? | try { | uninstallMethod.invoke(target, VMD::get) | } finally { | VDM::unget | } | whereas service could still hold onto the ref - which might be an issue if that ref is ServiceFactory, as ServiceFactory::unget could modify the actual created service. Leave it to the expense of the user? :-) Should we also do unget on the callbacks, or a callback doesn't really have proper usage if it's not "backed-up" by uncallback (which will actually take care of unget)? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266096#4266096 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266096

15 years, 1 month

1
0
0 / 0

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

by alesj

"thomas.diesler(a)jboss.com" wrote : | Anyhow, could you please describe how the MC/OSGiService integration would work from the user perspective. | This would be transparent to user, either one, MC or OSGi. * OSGi services will be exposed as MC beans * MC beans will be listed as a OSGi services "thomas.diesler(a)jboss.com" wrote : | Not sure if you are aware of this, but we already have some sort of MC/OSGiService integration which is detailed in the MicrocontainerService | This doesn't look very transparent. :-) I guess it's the MCService that checks for proper bean (type) access? You could probably use OSGi's ServiceFactory here, where the actual underlying bean name would be part of service's properties. "thomas.diesler(a)jboss.com" wrote : | Could you please add a comment to https://jira.jboss.org/jira/browse/JBOSGI-141 that details what added benefits your current integration work will bring to the user? | * http://java.dzone.com/articles/a-look-inside-jboss-microconta View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266051#4266051 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266051

15 years, 1 month

1
0
0 / 0

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

by thomas.diesler＠jboss.com

Hi Ales, when working on this, please also keep in mind that the standard wiring and injection mechanism in OSGi is Blueprint. If there is some sort of integration between MC and BP beans and services it should show up in the BP descriptor. The BP descriptor has a namespace extension build into it which could be used to declare or reference MC beans. If you also think of bringing the notion of OSGi service to the MC descriptor then that would be of secondary importance. Anyhow, could you please describe how the MC/OSGiService integration would work from the user perspective. Not sure if you are aware of this, but we already have some sort of MC/OSGiService integration which is detailed in the MicrocontainerService http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapProvidedBundles.htm... and tested in by the http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapProvidedExamples.ht... Could you please add a comment to https://jira.jboss.org/jira/browse/JBOSGI-141 that details what added benefits your current integration work will bring to the user? Thanks a bunch View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266027#4266027 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266027

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - How does bundle resolution work

by thomas.diesler＠jboss.com

Here is a short explanation of how bundle resolution (currently) works. The OSGiBundleClassLoadingDeployer creates the package capabilities/requirements that map to package exports/imports respectively. At runtime the MC iterates over all modules, all requirements, all capabilities. For every OSGiPackageCapability it callls | boolean OSGiPackageCapability.resolves(Module reqModule, Requirement requirement) | The initial implementation, that did not use an external resolver would compare the package name and various other constraints. If a match was determined, this method would return true and irrevocably associate the capability with the requirement. Effectively establishing the wire from the package exported to the importer. There are various problems with this approach. Conceptually, bundles cannot be resolved by simply looking at a single package import/export combination. If multiple exporters are available the first one this approach would find is not necessarily the one that can be used for the overall bundle resolution. Consider this | BundleC | exports A, B | imports A | | BundleD | exports A, | imports A, B, C | To resolve BundleC the resolver would have two choices. It could either use the self-import from of package A or import package A from BundleD. If it chooses the latter, both bundles cannot resolve because of the missing import of package C. Generally, because the resolve algorithm that is currently available in the MC is not yet suitable for the rich OSGi semantics we (i.e. Ales and I ) agreed to work on a pluggable module resolver. A correct resolver can reason about all possible wirings and may need to retry different wirings to find the best resolution. This becomes especially important when we add support for the uses clause on export packages. The related issues are https://jira.jboss.org/jira/browse/JBKERNEL-54 https://jira.jboss.org/jira/browse/JBKERNEL-55 In JBoss OSGi this is captured by https://jira.jboss.org/jira/browse/JBOSGI-151 The current workaround is that there is the notion of a resolver in the OSGi layer that somehow predetermines the wiring, which is triggered from PackageAdmin.resolveBundles | PackageAdmin.resolveBundles(Bundle[] bundleArr) | | // Resolve the bundles through the resolver | Resolver bundleResolver = bundleManager.getPlugin(ResolverPlugin.class); | List<OSGiBundleState> resolvableBundles = new ArrayList<OSGiBundleState>(); | for (Resolvable aux : bundleResolver.resolve(unresolvedBundles)) | resolvableBundles.add(OSGiBundleState.assertBundleState(aux.getBundle())); | The OSGiPackageCapability simply picks up the result from the Resolver and does not attempt do compute the resolution itself. | boolean OSGiPackageCapability.resolves(Module reqModule, Requirement requirement) | | // Get the exporter for this requirement | ExportPackage exporter = bundleResolver.getExporter(reqBundle, packageRequirement.getName()); | if (exporter == null) | return false; | The call into OSGiPackageCapability.resolves returns false for every combination but the one the Resolver has previously determined. This is of course still very inefficient and not the right place to do it apart from that the current BasicResolverImpl is (as the name suggests) indeed very basic (i.e. wrong). However it allows us to run the OSGi enterprise examples against the MC Framework on all supported target containers, which was the release criteria for Beta4. In future that or a similar resolver API would bubble up into the MC layer and become a native part of its module resolution algorithm. For the time being the notion of external resolver however needs to stay in order to make good progress on the OSGi core TCK. This has currently highest priority and will result in functionality that allows folks to be able to actually deploy standard OSGi bundles and see them work as they should on all supported target containers. An alternative approach would be, to disable the Resolver and somehow still pass all the enterprise osgi examples and functional tests that are there already. This was our first approach, but unfortunately proved infeasible - so the alternative of external resolution came about. merci View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265982#4265982 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265982

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: JBoss OSGi logging policy

by thomas.diesler＠jboss.com

anonymous wrote : | I can't run tests from inside eclipse without modifying it and I'm going to | forget to revert it from time to time on commits. | In every projects pom there is a comment that tells you what properties to set in the eclipse test configurations to achieve the same runtime behaviour as from the command line. For the Framework that would be | -Dlog4j.output.dir=${workspace_loc:jboss-osgi-framework/target} | -Dorg.jboss.osgi.framework.launch.bootstrapPath=bootstrap/jboss-osgi-bootstrap.xml | This is needed because the system properties that are defined on the surefire plugin are unfortunately not used by the eclipse test runs, which is a general problem that applies to all system properties that should be available at test runtime. I've seen test cases that duplicate the settings from the pom and hard code them into the test. This IMHO is not so good. Instead system properties should go into the eclipse test configuration. I also run tests from eclipse on a daily basis, once the props are set in eclipse its should be all good. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265977#4265977 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265977

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