search

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

[RSA] Remote Service Admin CT event accounting needs to be revisited #2361

Closed bjhargrave closed 10 years ago

bjhargrave commented 11 years ago

Original bug ID: BZ#2493 From: @bosschaert Reported version: R5

bjhargrave commented 11 years ago

Comment author: @bosschaert

The RSA CT makes a number of assertions about events. This happens in the testExportRSAListenerNotification(), testExportEventNotification(), testForceExportFailure() and possibly other tests. The accounting for these events has been changed in the CT for R5 but it looks like things aren't completely correct just yet. Some suggested changes (non-final) that I had to make to get an RSA implementation to pass are in commit 53d760daf467a6f6fcad01bf6735753da7978989 (branch davidb/rsa_ct_fixes3)

bjhargrave commented 11 years ago

Comment author: @bosschaert

org.osgi.test.cases.remoteserviceadmin.tb2.Activator also contains event-based logic that I think should be revisited too.

bjhargrave commented 10 years ago

Comment author: Bram de Kruijff <bram.dekruijff@luminis.eu>

I am not sure it the changes David mentions made it into eeg/rsa_1_1 at some point. There are a lot of comments and commented-out lines of code in this area.

I think the current state wrt the events is that they are logically correct and they do not cause issues with the Amdatu RI. However, they may be a bit brittle in implementation.

The general pattern is..

1) The test registers a service with certain properties 2) The test registers an eventlistener for any and all events 3) The test acts as a topology manager calling exportService on the RSA 4) The test makes assertions on the events that may have happened

This is OK, because the in step 1 the service registered has no exported interfaces. Thus, it does not seem to cause any race conditions with the RI topologymanager.

This is brittle, because there are assertions on (the number of) events without actually testing that received events are for the expected services or endpoints. Thus, services with exported interfaces and concurrent scenarios may cause race conditions.

An example of this issue wrt org.osgi.test.cases.remoteserviceadmin.tb2.Activator can be found at [0].

So IMHO matters could be improved upon by 1) being more explicit through listeners that block on specific event types for specific payloads instead of blocking for any event and only then asserting on the payload, and 2) not asserting on number of events unless that is the actual test.

[0] https://www.osgi.org/members/bugzilla/show_bug.cgi?id=2594

bjhargrave commented 10 years ago

Comment author: Bram de Kruijff <bram.dekruijff@luminis.eu>

May be something we want to address in R6. Reassigning to CT maintainer.

bjhargrave commented 10 years ago

Comment author: Marc Schaaf <marc.schaaf@fhnw.ch>

Made the event handling a more reliable in 4d7e8ce92dd6a5c3e6aa6b3abd14e7c55292709d. Closing it, if any more issues around the event handling arise we can reopen it.