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

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

by thomas.diesler＠jboss.com

Yes, all this exposes is when we have a certain functionality available in JBoss OSGi. An uncoordinated update of core components would simply result in the MC Framework not being usable in AS. This is something we don't want either ;-) If we need to update a core library in AS (i.e. one that we cannot simply replace), then there should be an AS issue created for that which is a dependency on the some JBoss OSGi release issue. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266726#4266726 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266726

15 years, 1 month

1
0
0 / 0

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

by alesj

"thomas.diesler(a)jboss.com" wrote : | Anyhow, the MC framework needs to work in AS and the OSGi examples must run in AS. This is not something you can do in an Eclipse unit test. | | It'd be good if you could trigger the integration tests as part of your normal commit routine. | Although I understand and support this, this is not always possible - see my latest commits. For me in order to move fwd, I need to work on Kernel 2.2.x, which is not yet in AS, and will only be available for AS6. The same will probably go for Adrian's work on CL's LifeCycle / Resolver. I guess this requires some automation on whether it even makes sense to run tests on AS. e.g. libs compatibility Since in this case you cannot solve the problem with a simple lib change, as the changes affect the stuff beyond encapsulated MC projects. e.g. ControllerContext::ungetTarget --> AS' JMX + MC int View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266720#4266720 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266720

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

anonymous wrote : | 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. ;-) | Sure, these are the laws I also work according to. anonymous wrote : | Why aren't there regression tests for these features in reactor/framework? | JBoss OSGi supports multiple OSGi frameworks, for the reason that standard OSGi is already usable in AS. What we do with the OSGi example and functional test is a specific solution to the general problem of Maven integration testing http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing Anyhow, the MC framework needs to work in AS and the OSGi examples must run in AS. This is not something you can do in an Eclipse unit test. I realize, that the building the installer, installing the framework, starting the target container, running the examples against the target container is not a practical prerequisite for an SVN commit. However, everybody should at least be aware of the functionality that already works and is being tested. One click on the public hudson instance can pickup potential integration issues, which can then be looked at and fixed locally. It'd be good if you could trigger the integration tests as part of your normal commit routine. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266714#4266714 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266714

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: PROPERTY_AUTO_START

by thomas.diesler＠jboss.com

Ok, here is the issue https://jira.jboss.org/jira/browse/JBDEPLOY-225 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266713#4266713 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266713

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Goals of OSGi integration

by thomas.diesler＠jboss.com

Thanks this is very helpful. anonymous wrote : | This worked until the latest changes. | Stuff needs to work in Hudson on all supported target contains http://jbmuc.dyndns.org:8280/hudson/ A successful Eclipse test run, is unfortunately not sufficient as a release criteria. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266711#4266711 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266711

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 : | The OSGi spec takes a different (and probably incorrect :-) view. | I disagree. A bundle that is INSTALLED has no classloader nor bundle context associated with it. You can use PackageAdmin for an attempt to resolve that bundle. If that fails, the bundle is still INSTALLED. If that succeeds the bundle is RESOLVED, you can then use bundle.start() to start the bundle (i.e. call BundleActivator). If that fails the bundle is still RESOLVED. In no case does the bundle get uninstalled if a transition to the RESOLVED or ACTIVE state fails. anonymous wrote : | So the solution is to add an ErrorHandler to the DeploymentControllerContext if it is an OSGi deployment, | Ok, here is the issue https://jira.jboss.org/jira/browse/JBDEPLOY-225 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266710#4266710 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266710

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: How does bundle resolution work

by thomas.diesler＠jboss.com

Ok, but this is not about classloading alone. The modules need to first have a correct wiring. If you install multiple bundles and want to resolve them at the same time there needs to be a non-trivial resolve algorithm that is aware of the rich osgi semantics, the complete set of already resolved bundles plus the set of bundles that still need resolving. Anyhow, I agree that all of this needs to bubble up into the MC and I'll create issues in the MC projects as I encounter them in the OSGi TCK work. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266707#4266707 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266707

15 years, 1 month

1
0
0 / 0

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

by thomas.diesler＠jboss.com

"adrian" wrote : | The ServiceFactory is just a lazy version of the service. i.e. you only construct it | if somebody wants to use it. Its still a singleton. It only controls when the object | is constructed (first access instead of upfront). | Not quite. The main purpose of the ServiceFactory is that every client (bundle) of the service gets its own individual instance of the service. The service implementation may be stateful and maintain state on behalf of the client bundle. If the same bundle gets the service multiple times, it will receive the same service instance. An internal usage count is used to determine when the service can cleanup its state (i.e. when the usage count is 0) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266702#4266702 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266702

15 years, 1 month

1
0
0 / 0

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

by thomas.diesler＠jboss.com

anonymous wrote : | As I've said, it should be Hudson or Maven that redirects logging to a file using the log4j.configuration system property. | yes, I've tried that by setting the surefire system properties. It worked for some test cases but not all. I didn't look into the log4j initialization to find out why it did not work for all cases. In another attempt to make you happy, I now added log4j-console.xml to the test resources. Please put the log4j.configuration property in your test setup like shown below. This should produce eclipse console logging. http://drop.io/sfodign View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266700#4266700 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266700

15 years, 1 month

1
0
0 / 0

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

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : | As part of the OSGi stuff, I've made the DeploymentUnit part of the MDR's | deployment level metadata. You should extend this concept so that the | dependency project can look for a "ServiceTracker" in the MDR rather than | a DeploymentUnit. The deployers project would then add the ServiceTracker | attachment by the default to the deployment level metadata. | Where is this code? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266618#4266618 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266618

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