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

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

by alesj

"adrian(a)jboss.org" wrote : | When you do any type of injection (or the api is invoked from somewhere else) | this should invoke the equivalent of get/unget of the ServiceTracker for that context. | What kind of logic would you hide in this get/unget ServiceTracker invocations? Or what would be the benefit of ServiceTracker actually getting the context as a parameter, and not just (for example) type parameter? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265871#4265871 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265871

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: No explicit control over bundle.start()

by thomas.diesler＠jboss.com

anonymous wrote : | No, that is / should be the right behavior, as you don't wanna have broken service stuck in some middle state. | It is legal to have a temporary error in the BundleActivator, for example because of an invalid service lookup. The same call might succeed at some later time. anonymous wrote : | Bundle::start should only be called after we're past CLASSLOADER stage. | At least in automated mode. If the user wants to do this before, it's his choice and potential fault. | There is explicit control over the transition from INSTALLED to RESOLVED via PackageAdmin. Also, a bundle that provides an export package transitions to RESOLVED when the importing bundle gets started. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265786#4265786 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265786

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Handle potential bundle:// protocol with VFS

by thomas.diesler＠jboss.com

anonymous wrote : | you're by-passing bundle's restrictions. | Instead you pass around bundle protocol based url, knowing the restrictions apply. | This is a good point. Thanks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265781#4265781 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265781

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: No explicit control over bundle.start()

by alesj

"thomas.diesler(a)jboss.com" wrote : | The MC Framework incorrectly uninstalls the bundle if there is a failure in bundle.start() | No, that is / should be the right behavior, as you don't wanna have broken service stuck in some middle state. The is a notion of ErrorHandler in Controller, which might be useful, if we decide to go down this path. Imho, the real problem is how we handle this Bundle::start. "thomas.diesler(a)jboss.com" wrote : | The controller context reached its required stage DESCRIBED after bundle install. A subsequent call to bundle.start() is supposed to transition to stages CLASSLOADER and then INSTALLED, which corresponds to the Bundle states RESOLVED and ACTIVE respectively. | Bundle::start should only be called after we're past CLASSLOADER stage. At least in automated mode. If the user wants to do this before, it's his choice and potential fault. "thomas.diesler(a)jboss.com" wrote : | Adrian, this seems to be a fundamental problem for which neither Ales nor I could come up with a solution. Could you perhaps have a look at this issue. | Actually I solved it in some hackish way. Afair, my problem was that I didn't know how to resolve cyclic bundles, but that's actually Controller's resolve problem as it doesn't know how to resolve cyclic dependencies in the same state. But yeah, I'm all for it that Adrian gets a stab at this problem. :-) * Bundle:start issue * cyclic bundle dependencies * resolve algorithm performance issue (EmanuelM has a good example of this) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265455#4265455 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265455

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Handle potential bundle:// protocol with VFS

by alesj

"thomas.diesler(a)jboss.com" wrote : Anybody can do | | | InputStream is = sysContext.getBundle(someId).getResource("/some-resource.txt").openStream() | | | No. e.g. * I don't have access to system bundle / context -- remember your KernelLocator hack ;-) * I don't wanna depend on OSGi api -- my code is 100% portable "thomas.diesler(a)jboss.com" wrote : | What is the use case where the URL format actually matters? | OK, you could use direct vfsx protocol, but then. like I alredy said, you're by-passing bundle's restrictions. Instead you pass around bundle protocol based url, knowing the restrictions apply. User could still of course do direct access, but the framework shouldn't encourage him to do so, hence a custom protocol that works more closely with the framework. Currently this is a simple prototype, but I guess this could/will come in handy when you need to pass resource access around to other pieces of the OSGi env; e.g. compendium, your interceptors, ... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265428#4265428 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265428

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Handle potential bundle:// protocol with VFS

by thomas.diesler＠jboss.com

Sorry, I still don't get it. Anybody can do | InputStream is = sysContext.getBundle(someId).getResource("/some-resource.txt").openStream() | The format of the url would be irrelevant in that case. What is the use case where the URL format actually matters? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265425#4265425 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265425

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - No explicit control over bundle.start()

by thomas.diesler＠jboss.com

https://jira.jboss.org/jira/browse/JBOSGI-99 The MC Framework incorrectly uninstalls the bundle if there is a failure in bundle.start() The controller context reached its required stage DESCRIBED after bundle install. A subsequent call to bundle.start() is supposed to transition to stages CLASSLOADER and then INSTALLED, which corresponds to the Bundle states RESOLVED and ACTIVE respectively. If the transition to INSTALLED fails, the controller context gets undeployed, which causes the bundle to transition to UNINSTALLED. The desired behaviour is: * on fail to resolve: remain in state INSTALLED * on fail to start: remain in state RESOLVED Adrian, this seems to be a fundamental problem for which neither Ales nor I could come up with a solution. Could you perhaps have a look at this issue. It is also related to PROPERTY_AUTO_START and the DeployerWrapper View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265383#4265383 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265383

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: PROPERTY_AUTO_START

by thomas.diesler＠jboss.com

There is also a test case for this, which should run in embedded and all supported target containers https://jira.jboss.org/jira/browse/JBOSGI-99 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265158#4265158 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265158

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: PROPERTY_AUTO_START

by thomas.diesler＠jboss.com

External bundle provisioning systems have different requirements on bundle start behaviour. Clients that require explicit control over bundle start * osgi management (web) console * osgi testsuite for embedded/remote frameworks Clients that require implicit bundle start * Hot deployment service that picks up bundles from the deploy folder Recent changes broke AS integration to the effect that bundles did not get started on sever startup. Related to http://www.jboss.org/index.html?module=bb&op=viewtopic&t=163633 Please verify that container integration related changes are valid. cheer View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265146#4265146 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265146

15 years, 1 month

1
0
0 / 0

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

by thomas.diesler＠jboss.com

To learn howto setup the hudson QA environment locally, have a look at http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapGettingStarted.html... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265144#4265144 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265144

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