On Fri, Aug 12, 2016 at 7:54 AM, Karel Haeck <karel.ha...@telenet.be> wrote: > > You typically use a serviceTracker in the test bundle to obtain a reference > to the component 's service. > See http://enroute.osgi.org/tutorial_base/600-testing.html for how to do > this in bndtools. > The service tracker open method will trigger the component's delayed > activation
I didn't realize that the service tracker could interact with DS. Thanks. > > Karel > > > On 12/08/2016 13:30, Benson Margulies wrote: >> >> Thank you all. Indeed, the component was not 'immediate', and that's >> why it wasn't set up. >> >> My task of the moment it to add pax-exam tests for some individual >> components; in the past, I only tested this stuff with broad >> functional tests. This has led me, on this particular occasion, end >> up trying to test this not-immediate component. >> >> How do other people create pax-exam tests for @Components that are not >> immediate? By adding DS metadata to pax-exam bundles? >> >> >> >> >> >> >> g! scr:info com.basistech.ws.worker.core.Worker >> *** Bundle: rosapi-worker-core (59) >> Component Description: >> Name: com.basistech.ws.worker.core.Worker >> Implementation Class: com.basistech.ws.worker.core.Worker >> Default State: enabled >> Activation: immediate >> Configuration Policy: ignore >> Activate Method: activate >> Deactivate Method: deactivate >> Modified Method: - >> Configuration Pid: [com.basistech.ws.worker.core.Worker] >> Services: >> com.basistech.ws.worker.api.WorkerInterface >> Service Scope: singleton >> Reference: BusService >> Interface Name: com.basistech.ws.worker.api.WorkerBusService >> Cardinality: 1..1 >> Policy: static >> Policy option: reluctant >> Reference Scope: bundle >> Reference: WorkerComponentServices >> Interface Name: com.basistech.ws.worker.core.WorkerComponentServices >> Cardinality: 1..1 >> Policy: static >> Policy option: reluctant >> Reference Scope: bundle >> Reference: WorkerConfiguration >> Interface Name: >> com.basistech.ws.worker.core.config.WorkerConfiguration >> Cardinality: 1..1 >> Policy: static >> Policy option: reluctant >> Reference Scope: bundle >> Component Description Properties: >> Component Configuration: >> ComponentId: 5 >> State: active >> SatisfiedReference: BusService >> Target: null >> Bound to: 39 >> Reference Properties: >> component.id = 3 >> component.name = com.basistech.ws.worker.bus.impl.BusService >> licensePathname = >> >> /Users/benson/x/rosapi1.5/worker/core/../../assemblies/common-configuration/src/main/resources/etc/rosapi/rlp-license.xml >> objectClass = [com.basistech.ws.worker.api.WorkerBusService] >> service.bundleid = 24 >> service.id = 39 >> service.pid = com.basistech.ws.bus >> service.scope = bundle >> SatisfiedReference: WorkerComponentServices >> Target: null >> Bound to: 56 >> Reference Properties: >> objectClass = >> [com.basistech.ws.worker.core.WorkerComponentServices] >> service.bundleid = 59 >> service.id = 56 >> service.scope = singleton >> SatisfiedReference: WorkerConfiguration >> Target: null >> Bound to: 40 >> Reference Properties: >> component.id = 6 >> component.name = >> com.basistech.ws.worker.core.config.WorkerConfigurationImpl >> configurationFilePathname = >> >> /Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml >> endpointsPathname = >> >> /Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml >> native-root = >> >> /var/folders/80/5l86669j3278_x4hlpntlz380000gp/T/nativeroot6966159272930866297 >> objectClass = >> [com.basistech.ws.worker.core.config.WorkerConfiguration] >> service.bundleid = 59 >> service.id = 40 >> service.pid = com.basistech.ws.worker >> service.scope = bundle >> subst = tsbus >> Component Configuration Properties: >> component.id = 5 >> component.name = com.basistech.ws.worker.core.Worker >> >> On Fri, Aug 12, 2016 at 6:05 AM, Ferry Huberts <maili...@hupie.com> wrote: >>> >>> >>> On 12/08/16 12:02, Carsten Ziegeler wrote: >>>>> >>>>> Thanks Carsten, that was my expectation but I was waiting for the >>>>> “inspect cap service” output to confirm. >>>>> >>>>> One thing that can be quite confusing is that the service >>>>> references, with cardinality of 1..1, are described as both >>>>> satisfied and unbound. This sounds like a contradiction until you >>>>> realise the component has not yet been instantiated. I assume that >>>>> SCR at this point does know which services it *will* bind when the >>>>> component is activated… maybe these could be shown here? >>> >>> >>> I think that would be misleading because when the bundle composition >>> changes >>> before activation is needed then a different resolution can/will be >>> activated. >>> >>>> Hmm, yeah we could do that - on the other hand "unbound" means it's >>>> satisfied, otherwise it would state the reference as "unsatisfied" >>>> :) Maybe, it's more a wording problem? >>>> >>>> Carsten >>>> >>> -- >>> Ferry Huberts >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> For additional commands, e-mail: users-h...@felix.apache.org >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
