osgi / bugzilla-archive

Archive of OSGi Alliance Specification Bugzilla bugs. The Specification Bugzilla system was decommissioned with the move to GitHub. The issues in this repository are imported from the Specification Bugzilla system for archival purposes.
0 stars 1 forks source link

[subsystem CT] is not very friendly with the other active bundles in the framework, hosting the subsystem implementation, which is being tested. #2345

Closed bjhargrave closed 10 years ago

bjhargrave commented 11 years ago

Original bug ID: BZ#2477 From: Teodor Todorov <t_todorov@prosyst.bg> Reported version: R5

bjhargrave commented 11 years ago

Comment author: Teodor Todorov <t_todorov@prosyst.bg>

Hello Colleagues,

The following methods from org.osgi.test.cases.subsystem.junit.SubsystemTest execute either Bundle.stop() or Bundle.start() on all bundles with the exception of the system bundle and the test bundle: protected void stopImplementation() protected void startImplementation()

My understanding is that the only bundle who is really meant to be started or stopped is the subsystem implementation bundle.

If this assumption holds true, could you please apply a minor fix about it, so that it is the only bundle stopped/started? It would allow execution of the test case in a custom (more complex) test environment than the bndtools, where there are also other active bundles.

Thanks and best regards, Teodor Todorov

bjhargrave commented 11 years ago

Comment author: John Ross <jwross@us.ibm.com>

I believe your assumption is correct. Those methods are used in the persistence tests, so stopping only the subsystems impl bundle should be sufficient. But how would the impl bundle be identified? What if an impl spanned multiple bundles? Perhaps the same technique in the DS CT could be used, which I understand is via a system property identifying the impl bundle?

bjhargrave commented 11 years ago

Comment author: Teodor Todorov <t_todorov@prosyst.bg>

Hello John,

Yes, a system property could be defined, that would describe the symbolic name(s) of the bundle(s), that implement the Subsystem service. If it is implemented via a few bundles, the property would describe a list of symbolic names, separated with ",".

If the property is not defined, the test case would stop all bundles - the current behavior of the test case. Otherwise it would stop only the listed bundle(s) in the value of the property.

This would support perfectly my setup.

Regards, Teodor

bjhargrave commented 10 years ago

Comment author: @bosschaert

John to include this as part of his current Subsystem CT work.

bjhargrave commented 10 years ago

Comment author: John Ross <jwross@us.ibm.com>

Fixed in https://www.osgi.org/members/gitweb/build.git/commit/f7aa85d88fb65c21850fd2294309cd6c5ef0733a.

bjhargrave commented 10 years ago

Comment author: @bjhargrave

(In reply to John Ross from comment BZ#4)

Fixed in https://www.osgi.org/members/gitweb/build.git/commit/ f7aa85d88fb65c21850fd2294309cd6c5ef0733a.

You should get the property from BundleContext.getProperty not System.getProperty. I recent went through all the CTs to make this change. Please change to use BundleContext.getProperty.

bjhargrave commented 10 years ago

Comment author: John Ross <jwross@us.ibm.com>

Fixed in https://www.osgi.org/members/gitweb/build.git/commit/abbad03e05f3334146f5b26c9d651e992cda564d.

bjhargrave commented 10 years ago

Comment author: @bjhargrave

(In reply to John Ross from comment BZ#6)

Fixed in https://www.osgi.org/members/gitweb/build.git/commit/ abbad03e05f3334146f5b26c9d651e992cda564d.

Thanks!