It's the same karaf. I fear that in Karaf 4.0.4 there is a coin being flipped to decide which set of gogo commands to use. I do not know how to get Karaf to use the real SCR command and not its own by changing what I type, maybe there's a way. It's another bundle start order business.
On Wed, Jul 6, 2016 at 12:24 PM, David Jencks <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> 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 >>>> >
