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 >>>> >>>> >>
