karaf@root>feature:install shell-compat karaf@root> karaf@root>scr:info Command not found: scr:info
On Wed, Dec 9, 2015 at 8:03 AM, Jean-Baptiste Onofré <[email protected]> wrote: > Gogo commands should work if shell-compat feature is installed. > > Regards > JB > > > > Sent from my Samsung device > > > -------- Original message -------- > From: Benson Margulies <[email protected]> > Date: 09/12/2015 12:34 (GMT+01:00) > To: [email protected] > Subject: Re: Bundle in mysterious scr state > > JB, I have some related issues for which I would really benefit from > using the 'real gogo scr' command. Is there some method I'm missing to > get to it? > > On Tue, Dec 8, 2015 at 9:00 PM, Benson Margulies <[email protected]> > wrote: >> Bingo! Thank you very much! >> >> On Tue, Dec 8, 2015 at 8:57 PM, Benson Margulies <[email protected]> >> wrote: >>> On Tue, Dec 8, 2015 at 8:49 PM, David Jencks <[email protected]> >>> wrote: >>>> The simplest explanation for the behavior change is that no-service >>>> components are immediate (there’s no service to request to trigger creation >>>> of the component) whereas components exposing a service are delayed unless >>>> you explicitly specify immediate. You could have put your system into a >>>> state where no one has actually requested the WebServiceAvailable service, >>>> so none of the network of components gets activated, and as soon as >>>> something gets the service, everything will start up. If you specify >>>> immediate=true and you get the old behavior, this is what happened :-). >>>> Then you can decide how lazily you want all these services to be >>>> instantiated. >>> >>> I guess I misread the doc on immediate to be 'true' when there was no >>> factory. Let me go turn it on. >>> >>> As a reported, I'm momentarily stumped on the scr:info command, having >>> done what you suggested to no good effect. >>> >>> >>>> >>>> I bet that if you removed the karaf scr command and rebuilt (or left out >>>> the bundle its in if that wouldn’t kill the console) you’d see the felix >>>> scr >>>> gogo command…. I thought I remember JB saying recently that karaf supported >>>> both karaf and gogo commands, so maybe the karaf one is hiding the >>>> same-named felix one. >>>> >>>> Felix scr logs way more info than you get in the info command, but it’s >>>> harder to interpret. You need to make sure the log service is recording >>>> debug level, and you need to set the felix scr configuration property >>>> >>>> ds.loglevel=debug >>>> >>>> If you are configuring ds using config admin, put this in the >>>> configuration. Otherwise you can set it as a framework property (not sure >>>> how to do this in karaf, but I imagine it’s possible). >>>> >>>> hope this helps >>>> david jencks >>>> >>>>> On Dec 8, 2015, at 5:26 PM, Benson Margulies <[email protected]> >>>>> wrote: >>>>> >>>>> The component state is '2' (ENABLED). >>>>> >>>>> I can now describe what brings on this mess. Here's a diff. In a >>>>> different bundle, in a different component, I change it from services >>>>> = {} to service = { some interface }. >>>>> >>>>> Thereafter, a whole slew of bundles get into this stuck state. In >>>>> particular, a bundle that is absolutely not depending on the one I >>>>> change. >>>>> >>>>> I don't think that plain gogo commands can be run in Karaf, but I >>>>> could be misinformed. >>>>> >>>>> David, short of doing the work of porting the modern SCR display code >>>>> from Felix into Karaf, any ideas about what to look at? >>>>> >>>>> Does SCR log anything I could enable to get a clue? >>>>> >>>>> diff --git >>>>> a/worker/service/src/main/java/com/basistech/ws/worker/service/WorkerService.java >>>>> >>>>> b/worker/service/src/main/java/com/basistech/ws/worker/service/WorkerService.java >>>>> index 572bcc6..9f7f22f 100644 >>>>> --- >>>>> a/worker/service/src/main/java/com/basistech/ws/worker/service/WorkerService.java >>>>> +++ >>>>> b/worker/service/src/main/java/com/basistech/ws/worker/service/WorkerService.java >>>>> @@ -15,6 +15,7 @@ >>>>> package com.basistech.ws.worker.service; >>>>> >>>>> import com.basistech.rosette.RosetteRuntimeException; >>>>> +import com.basistech.ws.common.WebServiceAvailable; >>>>> import com.basistech.ws.common.json.JsonUtils; >>>>> import com.basistech.ws.common.ticket.Ticket; >>>>> import com.basistech.ws.worker.api.WorkerInterface; >>>>> @@ -51,9 +52,11 @@ import java.util.concurrent.atomic.AtomicLong; >>>>> * This registers itself upon activation as a CXF JAX-RS Service. >>>>> */ >>>>> @Component(configurationPid = "com.basistech.ws.worker", >>>>> - /* No services; we're here to register with CXF. */ >>>>> - service = {}) >>>>> -public class WorkerService { >>>>> + // this service simply allows tests to wait for this thing to >>>>> be started. >>>>> + service = { WebServiceAvailable.class }, >>>>> + property = { "service=worker" } >>>>> +) >>>>> +public class WorkerService implements WebServiceAvailable { >>>>> private static final Logger LOG = >>>>> LoggerFactory.getLogger(WorkerService.class); >>>>> private static final String APPLICATION_X_JACKSON_SMILE = >>>>> "application/x-jackson-smile"; >>>>> private static final MediaType APPLICATION_X_JACKSON_SMILE_TYPE >>>>> >>>>> >>>>> On Tue, Dec 8, 2015 at 8:09 PM, David Jencks <[email protected]> >>>>> wrote: >>>>>> The gogo scr command is packaged in felix ds itself. If karaf >>>>>> supports gogo >>>>>> commands you ought to be able to see it. >>>>>> >>>>>> Most of those states haven’t existed in years. Are you trying to use >>>>>> the >>>>>> backwards compatibility bundle to avoid updating your command to show >>>>>> the >>>>>> new spec-defined state info from the DTOs? The model the backwards >>>>>> compatibility bundle relies on is really bogus. >>>>>> >>>>>> david jencks >>>>>> >>>>>> On Dec 8, 2015, at 4:38 PM, Benson Margulies <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Dependencies are too big. I will debug the command and tell you what I >>>>>> see >>>>>> when I get back home >>>>>> >>>>>> On Dec 8, 2015 7:29 PM, "Jean-Baptiste Onofré" <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> I mean share your code or bundle jar in order for me to try to >>>>>>> reproduce >>>>>>> and check the actual component state ;) >>>>>>> >>>>>>> Regards >>>>>>> JB >>>>>>> >>>>>>> On 12/09/2015 01:27 AM, Benson Margulies wrote: >>>>>>>> >>>>>>>> What do you mean by 'send the bundles'? >>>>>>>> >>>>>>>> On Dec 8, 2015 7:18 PM, "Jean-Baptiste Onofré" <[email protected] >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> Just checked, the two states that the command doesn't deal is the >>>>>>>> deprecated state: STATE_ENABLED, and STATE_DESTROYED >>>>>>>> >>>>>>>> Maybe the component are in this state. >>>>>>>> >>>>>>>> @Benson: can you send the bundles to test if the component is not >>>>>>>> in >>>>>>>> the "deprecated" state ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Regards >>>>>>>> JB >>>>>>>> >>>>>>>> On 12/09/2015 01:14 AM, Jean-Baptiste Onofré wrote: >>>>>>>> >>>>>>>> The ScrDetails command basically does: >>>>>>>> >>>>>>>> - component.getState() >>>>>>>> - then a switch on the int to display human readable string. >>>>>>>> >>>>>>>> switch (componentState) { >>>>>>>> case Component.STATE_ACTIVE: >>>>>>>> retVal = "ACTIVE"; >>>>>>>> break; >>>>>>>> case Component.STATE_ACTIVATING: >>>>>>>> retVal = "ACTIVATING"; >>>>>>>> break; >>>>>>>> case Component.STATE_DEACTIVATING: >>>>>>>> retVal = "DEACTIVATING"; >>>>>>>> break; >>>>>>>> case Component.STATE_DISABLED: >>>>>>>> retVal = "DISABLED"; >>>>>>>> break; >>>>>>>> case Component.STATE_DISABLING: >>>>>>>> retVal = "DISABLING"; >>>>>>>> break; >>>>>>>> case Component.STATE_DISPOSED: >>>>>>>> retVal = "DISPOSED"; >>>>>>>> break; >>>>>>>> case Component.STATE_DISPOSING: >>>>>>>> retVal = "DISPOSING"; >>>>>>>> break; >>>>>>>> case Component.STATE_ENABLING: >>>>>>>> retVal = "ENABLING"; >>>>>>>> break; >>>>>>>> case Component.STATE_FACTORY: >>>>>>>> retVal = "FACTORY"; >>>>>>>> break; >>>>>>>> case Component.STATE_REGISTERED: >>>>>>>> retVal = "REGISTERED"; >>>>>>>> break; >>>>>>>> case Component.STATE_UNSATISFIED: >>>>>>>> retVal = "UNSATISFIED"; >>>>>>>> break; >>>>>>>> >>>>>>>> So, it would mean that the component is not in the previous >>>>>>>> state >>>>>>>> (another one maybe missing in the switch). >>>>>>>> >>>>>>>> Regards >>>>>>>> JB >>>>>>>> >>>>>>>> >>>>>>>> On 12/09/2015 01:03 AM, David Jencks wrote: >>>>>>>> >>>>>>>> I have no idea what this command you are using is, can >>>>>>>> you >>>>>>>> show the >>>>>>>> output from the gogo scr:info command for this component? >>>>>>>> >>>>>>>> thanks >>>>>>>> david jencks >>>>>>>> >>>>>>>> On Dec 8, 2015, at 3:51 PM, Benson Margulies >>>>>>>> <[email protected] <mailto:[email protected]>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> I have one particular bundle that gets into this >>>>>>>> stuck >>>>>>>> state since I >>>>>>>> made some changes that should be completely unrelated >>>>>>>> to >>>>>>>> it. I badly >>>>>>>> want to explain why it's stuck. I am reduced to a >>>>>>>> sort >>>>>>>> of 'bisect' >>>>>>>> procedure of carefully remaking the changes to see if >>>>>>>> I >>>>>>>> can isolate >>>>>>>> the problem, since the scr:details command does not >>>>>>>> explain why it's >>>>>>>> left 'null'. >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 6:48 PM, Jean-Baptiste Onofré >>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> Karaf 4.0.2 already uses SCR 2.0.2. >>>>>>>> >>>>>>>> Does it always occur or just on some bundles ? >>>>>>>> >>>>>>>> Regards >>>>>>>> JB >>>>>>>> >>>>>>>> >>>>>>>> On 12/09/2015 12:44 AM, Benson Margulies wrote: >>>>>>>> >>>>>>>> >>>>>>>> Karaf 4.0.2 ... It's scr 2.0.2, but I guess >>>>>>>> the >>>>>>>> command is not so hot. >>>>>>>> >>>>>>>> eature:info scr >>>>>>>> Feature scr 4.0.2 >>>>>>>> Description: >>>>>>>> Declarative Service support >>>>>>>> Feature has no configuration >>>>>>>> Feature has no configuration files >>>>>>>> Feature has no dependencies. >>>>>>>> Feature contains followed bundles: >>>>>>>> >>>>>>>> >>>>>>>> mvn:org.apache.felix/org.apache.felix.metatype/1.1.2 start-level=30 >>>>>>>> >>>>>>>> >>>>>>>> mvn:org.apache.felix/org.apache.felix.scr/2.0.2 >>>>>>>> start-level=30 >>>>>>>> >>>>>>>> >>>>>>>> mvn:org.apache.felix/org.apache.felix.scr.compat/1.0.2 >>>>>>>> start-level=30 >>>>>>>> Feature contains followed conditionals: >>>>>>>> Conditional(management) has no configuration >>>>>>>> Conditional(management) has no configuration >>>>>>>> files >>>>>>>> Conditional(management) has no dependencies. >>>>>>>> Conditional(management) contains followed >>>>>>>> bundles: >>>>>>>> >>>>>>>> >>>>>>>> mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.2 >>>>>>>> start-level=30 >>>>>>>> Conditional(webconsole) has no configuration >>>>>>>> Conditional(webconsole) has no configuration >>>>>>>> files >>>>>>>> Conditional(webconsole) has no dependencies. >>>>>>>> Conditional(webconsole) contains followed >>>>>>>> bundles: >>>>>>>> >>>>>>>> >>>>>>>> mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2 >>>>>>>> start-level=30 >>>>>>>> Conditional(shell) has no configuration >>>>>>>> Conditional(shell) has no configuration files >>>>>>>> Conditional(shell) has no dependencies. >>>>>>>> Conditional(shell) contains followed bundles: >>>>>>>> >>>>>>>> >>>>>>>> mvn:org.apache.karaf.scr/org.apache.karaf.scr.command/4.0.2 >>>>>>>> start-level=30 >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 6:11 PM, David Jencks >>>>>>>> <[email protected] >>>>>>>> <mailto:[email protected]>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> This looks like a back level scr? maybe >>>>>>>> 1.8.x? The info from those >>>>>>>> makes it really hard to tell what’s going >>>>>>>> on. Is it >>>>>>>> configuration required >>>>>>>> and no configuration? >>>>>>>> >>>>>>>> david jencks >>>>>>>> >>>>>>>> >>>>>>>> On Dec 8, 2015, at 2:39 PM, Benson >>>>>>>> Margulies <[email protected] >>>>>>>> <mailto:[email protected]>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Here's a bundle. The bundle is >>>>>>>> active, >>>>>>>> its references are satisfied, >>>>>>>> but its state is null. What's it >>>>>>>> stuck >>>>>>>> on? >>>>>>>> >>>>>>>> >>>>>>>> 36 | Active | 80 | >>>>>>>> 0.7.105.v20151208100035 | >>>>>>>> rosapi-worker-bus >>>>>>>> >>>>>>>> karaf@root>scr:details >>>>>>>> >>>>>>>> com.basistech.ws.worker.bus.impl.BusService >>>>>>>> Component Details >>>>>>>> Name : >>>>>>>> >>>>>>>> com.basistech.ws.worker.bus.impl.BusService >>>>>>>> State : null >>>>>>>> References >>>>>>>> Reference : Bus >>>>>>>> State : satisfied >>>>>>>> Multiple : single >>>>>>>> Optional : mandatory >>>>>>>> Policy : static >>>>>>>> Service Reference : No Services >>>>>>>> bound >>>>>>>> Reference : ConfigAdmin >>>>>>>> State : satisfied >>>>>>>> Multiple : single >>>>>>>> Optional : mandatory >>>>>>>> Policy : static >>>>>>>> Service Reference : No Services >>>>>>>> bound >>>>>>>> karaf@root> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Jean-Baptiste Onofré >>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>> http://blog.nanthrax.net >>>>>>>> Talend - http://www.talend.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Jean-Baptiste Onofré >>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>> http://blog.nanthrax.net >>>>>>>> Talend - http://www.talend.com >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jean-Baptiste Onofré >>>>>>> [email protected] >>>>>>> http://blog.nanthrax.net >>>>>>> Talend - http://www.talend.com >>>>>> >>>>>> >>>>
