Is that the same karaf? The first scr:list looks like the new format and the second like the really old format. There have been some shenanigans where karaf thought they knew better than DS how to write a gogo command, so maybe only the command is the wrong one rather than the DS implementation, but something appears really different on restart.
david jencks > On Jul 6, 2016, at 9:18 AM, Benson Margulies <ben...@basistech.com> wrote: > > Here's how I got into this. > > I have this Karaf assembly. If I start if just after it is built, it > works fine. If I stop and restart it, it fails, because the CXF HTTP > transport does not start in time. > > So, I added @References to ensure that the transport starts first. > Then, I hit the problem reported in this thread: a component refuses > to start for lack of a configuration pid whose file is sitting right > there. > > If I delete the karaf data directory again, everything is fine. > > scr:list goes: > > karaf@root>scr:list > BundleId Component Name Default State > Component Id State PIDs (Factory PID) > [ 44] com.basistech.ws.common.InitializeS3FSService enabled > [ 1] [active ] > [ 44] com.basistech.ws.common.metrics.MetricsRegistryServiceImpl enabled > [ 2] [active ] com.basistech.ws.metrics > [ 45] com.basistech.ws.frontend.transport.anvils.impl.AnvilsTransportImpl > enabled > [ 19] [active ] com.basistech.ws.transport.http > ... > > > If I stop and start again, > > scr:list switches format to: > > karaf@root>scr:list > ID | State | Component Name > ----------------------------------------------------------------------------------------------- > -1 | UNSATISFIED | > com.basistech.ws.logstashrequesttracker.impl.LogstashRequestTracker > 1 | ACTIVE | com.basistech.ws.common.InitializeS3FSService > 2 | ACTIVE | com.basistech.ws.common.metrics.MetricsRegistryServiceImpl > 3 | ACTIVE | > com.basistech.ws.frontend.transport.anvils.impl.AnvilsTransportImpl > 4 | ACTIVE | > com.basistech.ws.frontend.transport.anvils.impl.RosapiDnsResolver > 5 | ACTIVE | com.basistech.ws.embeddedworker.impl.EmbeddedTransport > 6 | ACTIVE | com.basistech.ws.usage.impl.LocalUsageTracker > ... > > (That first component is supposed to be unsatisfied) All my components > appear to be alive. > > and > > But a swath of my CXF services stop working, even though their > components are activated and they have made the call to start the > service. > > > On Wed, Jul 6, 2016 at 12:10 PM, Benson Margulies <ben...@basistech.com> > wrote: >> com.basistech.worker.service.cfg exists. >> >> And when I stopped and started karaf, the component got itself activated. >> >> >> >> On Wed, Jul 6, 2016 at 12:01 PM, David Jencks <david.a.jen...@gmail.com> >> wrote: >>> You have configuration policy require and there is no component >>> configuration shown, so the configuration is missing. >>> >>> If at least one matching configuration were available to DS you’d see one >>> component configuration for each configuration, and then you could tell if >>> the references were satisfied or not from the references section of the >>> component configuration. >>> >>> thanks >>> david jencks >>> >>>> On Jul 6, 2016, at 8:52 AM, Benson Margulies <ben...@basistech.com> wrote: >>>> >>>> Folks, I have a service that isn't starting, and I cannot see why. Any >>>> clues? >>>> >>>> >>>> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService >>>> Component Details >>>> Name : com.basistech.ws.worker.service.WorkerService >>>> State : UNSATISFIED >>>> Properties : >>>> service=worker >>>> References >>>> >>>> ----- >>>> >>>> karaf@root>scr:info com.basistech.ws.worker.service.WorkerService >>>> *** Bundle: com.basistech.ws.rosapi-worker-service (144) >>>> Component Description: >>>> Name: com.basistech.ws.worker.service.WorkerService >>>> Default State: enabled >>>> Activation: immediate >>>> Configuration Policy: require >>>> Activate Method: activate >>>> Deactivate Method: deactivate >>>> Modified Method: - >>>> Configuration Pid: [com.basistech.worker.service] >>>> Services: >>>> com.basistech.ws.common.WebServiceAvailable >>>> Service Scope: singleton >>>> Reference: CxfTransport >>>> Interface Name: org.apache.cxf.transport.http.DestinationRegistry >>>> Cardinality: 1..1 >>>> Policy: static >>>> Policy option: reluctant >>>> Reference Scope: bundle >>>> Reference: Metrics >>>> Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService >>>> Cardinality: 1..1 >>>> Policy: static >>>> Policy option: reluctant >>>> Reference Scope: bundle >>>> Reference: Worker >>>> Interface Name: com.basistech.ws.worker.api.WorkerInterface >>>> Cardinality: 1..1 >>>> Policy: static >>>> Policy option: reluctant >>>> Reference Scope: bundle >>>> Properties: >>>> service = worker >>>
