Gogo commands should work if shell-compat feature is installed.
RegardsJB
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
>>>>>
>>>>>
>>>
